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SYSTEM AND METHOD FOR MEDICAL DATA TRACKING, ANALYSIS AND 
REPORTING FOR A HEALTHCARE SYSTEM 
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TECHNICAL FIELD 

2 5 This invention relates generally to healthcare / medication delivery systems and medical 

information technology systems. More particularly, the present invention relates to a remote 
user interface and system for interfacing with medical devices and systems within a healthcare / 
medication delivery system and/or medical information technology system. Further, the present 
invention relates to healthcare systems for monitoring medication delivery and/or vital signs of a 

30 patient within a healthcare facility. Even further, the present invention relates to tracking, 

analysis, and/or reporting of medication delivery data. 
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BACKGROUND 

Patient care systems typically include computer networks, medical devices for treating a 
patient, and controls for the medical devices. Although patient care systems have improved 
through the use of computerized automation systems and methods, patient care systems continue 
5 to rely heavily upon manual data management processes for medical devices and controls for 

medical devices. For example, nursing stations are typically connected to the computer 
networks in modern hospitals, but it is unusual for the computer network to extend to a patient's 
room. Computer networks offer the opportunity for automated data management processing 
including the operating and monitoring of medical devices and controls for the medical devices 
10 at the point-of-care. Despite advances in the field, automated data management technology has 

been underutilized for point-of-care applications due to lack of more efficient systems and 
methods. As dependence on automated technology grows, a need arises in providing a versatile 
multi-purpose interface for use with components of such systems and/or subsystems. 

15 SUMMARY 

One embodiment is a remote multi-purpose user interface for medical devices and 
systems within a healthcare / medication delivery system and/or medication information 
technology system. The multi-purpose user interface has a housing, a processor, a memory, a 
communications interface for providing communication between the user interface and a 
20 medical device / controller and for providing communications between the user interface and a 

first central computer, and a display for displaying a medical prompt and for displaying medical 
information received from the first central computer. 

In one embodiment, the user interface is programmed to display a medical prompt that is 
an infusion prompt for at least two channels to be controlled by user interface, the medical 
25 device or first central computer. 

In one embodiment, the user interface housing can be removably connected to the 
medical device. 

In one embodiment, the medical device is a controller for a medical device. 
In one embodiment, the user interface can be programmed to control the operation of 
30 medical device. 

In one embodiment, the first central computer can be programmed to control the 
operation of the medical device. 
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In one embodiment, the user interface receives a first listener task from the first central 
computer to listen for medical information from the first central computer. The user interface 
can also receive a second listener task from the first central computer for the user interface to 
listen for medical information from the medical device. The user interface can be programmed 
to receive status information regarding the operation of the medical device, and display the 
status information on the display, the medical prompt is an infusion prompt displayed on the 
display of the user interface and wherein the infusion prompt comprises an infusion prompt for 
at least two channels controlled by the medical device. 

In one embodiment, the user interface is programmed to display a selection prompt on 
the display for selecting at least one medical device to associate the user interface with. The 
medical device can be of a first type and another medical device can be of a second type. The 
user interface can be further programmed to operate in accordance with a first personality 
associated with the first type and further programmed to operate in accordance with a second 
personality associated with the second type. The user interface can also be programmed to 
receive the identification of a medical device to associate the user interface with manually or 
automatically, as well as the selection and programming of the personality manually or 
automatically. 

Other embodiments, features, aspects, and advantages will become apparent from the 
following drawings, detailed description, and claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The invention can be better understood with reference to the following drawings. The 
components in the drawings are not necessarily to scale, emphasis instead being placed upon 
clearly illustrating the principles of the present invention. In the drawings, like reference 
numerals designate corresponding parts throughout the several views. 

FIGURE 1 is a simplified graphical representation of a patient care system. The patient 
care system includes a pharmacy computer, a central system, and a digital assistant at a 
treatment location; 

FIGURE 2 is a block diagram of a computer system representative of the pharmacy 
computer, the central system, and/or the digital assistant of FIGURE 1. The system includes an 
infusion system or a portion thereof; 

FIGURE 3 is a simplified graphical representation of portions of the patient care system 
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of FIGURE 1; 

FIGURE 4 is a block diagram showing functional components of the patient care system 
of FIGURE 1; 

FIGURE 5 is an exemplar computer screen for implementing various functions of the 
patient care system of FIGURE 1; 

FIGURE 6 is a block diagram showing functional components of the infusion system of 
FIGURE 2. The functional components include, inter alia, blocks for setting infusion system 
parameters, infusion order creation, infusion order preparation, medication administration, 
infusion order modifications, and messaging; 

FIGURE 7 is a block diagram showing functional components for the setting of infusion 
system parameters of FIGURE 6; 

FIGURE 8 is a block diagram showing functional components for the infusion order 
creation of FIGURE 6; 

FIGURE 9 is a block diagram showing functional components for the infusion order 
preparation of FIGURE 6; 

FIGURE 10 is a block diagram showing functional components for the medication 
administration of FIGURE 6; 

FIGURE 11 is a block diagram showing functional components for infusion order 
documentation, infusion order modifications, and messaging of FIGURE 6; 

FIGURE 12 is a view of an emergency notification system, illustrating communication; 

FIGURE 13 is a view of an emergency notification interface from the perspective of a 
notifying party, illustrating the preferred notification options made available to the notifying 
party by the emergency notification system; 

FIGURE 14 is a view of an emergency notification interface from the perspective of a 
target party, illustrating the preferred emergency information received by the target party; 

FIGURE 15 is one embodiment of a flowchart of an alarm/alert escalation process; 

FIGURE 16A is a view of an alarm/alert interface screen; 

FIGURE 16B is another view of an alarm/alert interface screen; 

FIGURE 17 is another view of an alarm/alert interface screen; 

FIGURE 18 is a view of an interface screen from the clinician's handheld device; 

FIGURE 19 is a view of an interface screen of a login process; 

FIGURE 20 is a view of another interface screen of the login process of FIGURE 19; 
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FIGURE 21 is a view of a unit selection interface screen; 

FIGURE 22 is a view of a shift selection interface screen; 

FIGURE 23 is a view of a patient view interface screen; 

FIGURE 24 is a view of a patient selection interface screen; 
5 FIGURE 25 is a view of a patient information menu interface screen; 

FIGURE 25A is a view of an allergies and height/weight interface screen; 

FIGURE 25B is a view of a medication history interface screen; 

FIGURE 25C is a view of a lab results interface screen; 

FIGURE 26 is a view of a medication delivery schedule interface screen; 
10 FIGURE 26 A is another view of an interface screen of the medication delivery schedule 

process of FIGURE 26; 

FIGURE 27A is a view of an interface screen of a workflow infusion stop; 

FIGURE 27B is another view of an interface screen of a workflow infusion stop; 

FIGURE 27C is a view of an interface screen of a workflow to resume an infusion; 
15 FIGURE 27D is another view of an interface screen of a workflow to resume an 

infusion; 

FIGURE 28 is another view of an interface screen of the medication delivery schedule 
process of FIGURE 26; 

FIGURE 29 is a view of a missed medication interface screen; 
FIGURE 30 is another view of the interface screen of FIGURE 29; 
FIGURE 31 is another view of the interface screen of FIGURE 29; 
FIGURE 32 is a view of a schedule interface screen; 
FIGURE 33 is a view of a medication interface screen; 
FIGURE 34 is a view of a scan interface screen; 
FIGURE 35 is a view of another scan interface screen; 
FIGURE 36 is a view of a medication administration interface screen; 
FIGURE 37 is a view of a route verification interface screen; 
FIGURE 38 is a view of a scan pump channel interface screen; 
FIGURE 38A is a view of another scan pump channel interface screen; 
FIGURE 39 is a view of a comparison interface screen; 
FIGURE 39A is another view of a comparison interface screen; 
FIGURE 40 is another view of a comparison interface screen; 



25 
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FIGURE 41 is another view of a comparison interface screen; 
FIGURE 42 is another view of a comparison interface screen; 
FIGURE 43 is a view of a pump status interface screen; 
FIGURE 44 is a view of a flow rate history interface screen; 
FIGURE 45 A is a view of a communication loss interface screen; 
FIGURE 45B is a view of a communication loss interface screen; 
FIGURE 46 is a view of a low battery interface screen; 
FIGURE 47 is a view of a hub; 

FIGURE 48 is a view of a variety of icons utilized in the interface screens; 
FIGURE 49 is a view of a record administration results interface screen; 
FIGURE 50 is a view of a medication order having a monitoring parameter link; 
FIGURE 50A is a view of a monitoring parameter entry interface screen; 
FIGURE 51 is a view of a cycle count interface screen; 
FIGURE 52 is a flowchart of an order comparison process; 

FIGURE 53 is a schematic diagram of a flow control system where a micro- 
electromechanical system (MEMS) element is connected to a line set; 

FIGURE 54 is a simplified block diagram of software components loaded on the first 
central computer of FIGURE 3; 

FIGURE 55 A - FIGURE 55C is a flowchart of an example administer infusion process; 

FIGURE 56 is a flowchart of an example channel scanning process; 

FIGURE 57A - FIGURE 57B is a flowchart of an example change pump channel 
process; 

FIGURE 58 is a flowchart of another example channel scanning process; 
FIGURE 59 is a flowchart of yet another example channel scanning process; 
FIGURE 60 is a flowchart of an example stop/discontinue infusion process; 
FIGURE 61 is a flowchart of an example resume infusion process; 
FIGURE 62 is a flowchart of an example remove pump process; and, 
FIGURE 63 - FIGURE 69 is a flowchart of an example authentication process. 
FIGURE 70 is a system layout for additional embodiments relating to a remote user 
interface. 

FIGURE 71 is a diagram of a pump data and monitoring data system of the present 
invention; 
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FIGURE 72 is a screen shot for an interface device of the system of FIGURE 71; 

FIGURE 73 is a further screen shot for an interface device of the system of FIGURE 71; 

FIGURE 74 is a further screen shot for an interface device of the system of FIGURE 7 1 ; 

FIGURE 75 is a further screen shot for an interface device of the system of FIGURE 7 1 ; 

5 FIGURE 76 is a tabular report showing error near misses by unit for use with at least the 

embodiments of previous FIGURES; 

FIGURE 77 is a tabular report showing error near misses for use with at least the 
embodiments of previous FIGURES; 

FIGURE 78 is a graphical report showing error near misses by medication for use with 
10 at least the embodiments of previous FIGURES; 

FIGURE 79 is a tabular report showing error near misses by medication for use with at 
least the embodiments of previous FIGURES; 

FIGURE 80 is a graphical report showing error near misses by medication for use with 
at least the embodiments of previous FIGURES; 
15 FIGURE 81 is a tabular report showing error near misses by medication for use with at 

least the embodiments of previous FIGURES; 

FIGURE 82 is a tabular report showing scan errors for use with at least the embodiments 
of previous FIGURES; 

FIGURE 83 is a view of a selection criteria screen for use with at least the embodiments 
20 of previous FIGURES ; 

FIGURE 84 is a graphical report showing wrong time near misses for use with at least 
the embodiments of previous FIGURES; 

FIGURE 85 is a tabular report showing wrong time near misses by unit for use with at 
least the embodiments of previous FIGURES; 
2 5 FIGURE 86 is a graphical report showing wrong time near misses for use with at least 

the embodiments of previous FIGURES; 

FIGURE 87 is a tabular report showing wrong time near misses for use with at least the 
embodiments of previous FIGURES; 

FIGURE 88 is a graphical report showing wrong time near misses by medication for use 
30 with at least the embodiments of previous FIGURES; 

FIGURE 89 is a tabular report showing wrong time near misses by medication and unit 
for use with at least the embodiments of previous FIGURES; 

FIGURE 90 is a graphical report showing wrong time near misses by medication for use 
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with at least the embodiments of previous FIGURES; 

FIGURE 91 is a tabular report showing wrong time near misses by medication for use 
with at least the embodiments of previous FIGURES; 

FIGURE 92 is a first page of a tabular report showing wrong time errors with reason 
5 codes for use with at least the embodiments of previous FIGURES; 

FIGURE 93 is a second page of the tabular report of FIGURE 92 showing wrong time 
errors with reason codes for use with at least the embodiments of previous FIGURES; 

FIGURE 94 is a tabular report showing an infusion flow rate history for use with at least 
the embodiments of previous FIGURES; 
10 FIGURE 95 is a tabular report showing an infusion rate and mode comparison by unit 

for use with at least the embodiments of previous FIGURES; 

FIGURE 96 is a tabular report showing an infusion rate and mode comparison for use 
with at least the embodiments of previous FIGURES; 

FIGURE 97 is a tabular report showing an infusion flow rate comparison for use with at 
15 least the embodiments of previous FIGURES; 

FIGURE 98 is a tabular report showing an infusion rate comparison by medication and 
unit for use with at least the embodiments of previous FIGURES; 

FIGURE 99 is a tabular report showing an infusion rate comparison by medication for 
use with at least the embodiments of previous FIGURES; 
20 FIGURE 100 is a tabular report showing an infusion flow rate comparison for use with 

at least the embodiments of previous FIGURES; 

FIGURE 101 is a graphical report showing infusion flow rate comparison results for use 
with at least the embodiments of previous FIGURES; 

FIGURE 102 is a tabular report showing infusion flow rate comparisons by patient for 

2 5 use with at least the embodiments of previous FIGURES; 

FIGURE 103 is a graphical report showing alerts relating to dose and rate by unit for use 
with at least the embodiments of previous FIGURES; 

FIGURE 104 is a tabular report showing alerts by unit for use with at least the 
embodiments of previous FIGURES; 

3 0 FIGURE 105 is a graphical report showing alerts relating to dose and rate for use with at 

least the embodiments of previous FIGURES; 

FIGURE 106 is a tabular report showing alerts for use with at least the embodiments of 
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previous FIGURES; 

FIGURE 107 is a graphical report showing alerts relating to dose and rate by medication 
for use with at least the embodiments of previous FIGURES; 

FIGURE 108 is a tabular report showing alerts by medication for use with at least the 
5 embodiments of previous FIGURES; 

FIGURE 109 is a graphical report showing total alarms and alerts by unit for use with at 
least the embodiments of previous FIGURES; 

FIGURE 110 is a tabular report showing total alarms and alerts by unit for use with at 
least the embodiments of previous FIGURES; 
10 FIGURE 111 is a graphical report showing total alarms and alerts for use with at least 

the embodiments of previous FIGURES; 

FIGURE 112 is a tabular report showing total alarms and alerts for use with at least the 
embodiments of previous FIGURES; 

FIGURE 113A is a graphical report showing total alarms and alerts for use with at least 
15 the embodiments of previous FIGURES; 

FIGURE 113B is a graphical report showing total alarms and alerts by condition for use 
with at least the embodiments of previous FIGURES; 

FIGURE 1 14 is a tabular report showing total alarms and alerts by condition for use with 
at least the embodiments of previous FIGURES; 
2 0 FIGURE 1 15A is a graphical report showing an alarm/alert history by code for use with 

at least the embodiments of previous FIGURES; 

FIGURE 115B is a graphical report showing an alarm/alert history by device for use 
with at least the embodiments of previous FIGURES; 

FIGURE 116 is a table listing codes and alarm descriptions for use with at least the 
25 embodiments of previous FIGURES; 

FIGURE 1 17 is a tabular report showing an alarm/alert history for use with at least the 
embodiments of previous FIGURES; 

FIGURE 118 is a tabular report showing an alarm/alert history by alarm condition for 
use with at least the embodiments of previous FIGURES; 
30 FIGURE 1 19A is a graphical report showing an alarm/alert history by response time for 

use with at least the embodiments of previous FIGURES; 

FIGURE 119B is a graphical report showing cleared/silenced alarms and alerts for use 
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with at least the embodiments of previous FIGURES; 

FIGURE 120 is a table listing codes and alarm descriptions for use with at least the 
embodiments of previous FIGURES; 

FIGURE 121 is a tabular report showing an alarm/alert resolution history by 
5 cleared/silenced time for use with at least the embodiments of previous FIGURES; 

FIGURE 122A is a graphical report showing an alarm/alert history by device for use 
with at least the embodiments of previous FIGURES; 

FIGURE 122B is a graphical report showing an alarm/alert history by device for use 
with at least the embodiments of previous FIGURES; 
10 FIGURE 123 is a tabular report showing an alarm/alert history by unit for use with at 

least the embodiments of previous FIGURES; 

FIGURE 124 is a graphical report showing an alert/alarm summary by medication for 
use with at least the embodiments of previous FIGURES; 

FIGURE 125 is a tabular report showing an alert/alarm summary by medication and unit 
15 for use with at least the embodiments of previous FIGURES; 

FIGURE 126 is a graphical report showing an alert/alarm summary by medication for 
use with at least the embodiments of previous FIGURES; 

FIGURE 127 is a tabular report showing an alert/alarm summary by medication for use 
with at least the embodiments of previous FIGURES; and, 
20 FIGURE 128 is a screen/report flow chart showing a report hierarchy for use with at 

least the embodiments of previous FIGURES. 

DETAILED DESCRIPTION 

While this invention is susceptible of embodiments in many different forms, there is 
2 5 shown in the drawings and will herein be described in detail a preferred embodiment of the 

invention. The present disclosure is to be considered as an exemplification of the principles of 
the invention and is not intended to limit the broad aspect of the invention to the embodiment 
illustrated. 

FIGURE 1 is a graphical representation of a patient care system. In one embodiment, 
30 the patient care system 100 includes a pharmacy computer 104, a central system 108, and a 

treatment location 106, linked by a network 102. The patient care system 100 also includes an 
infusion system 210, also referred to as a healthcare system, as shown in FIGURE 2. Infusion 
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system 210 is a medication system preferably implemented as a computer program, and in 
particular a module or application (i.e., a program or group of programs designed for end users), 
resident on one or more electronic computing devices within the patient care system 100. As 
described in detail further herein, the infusion system 210 links clinicians, such as physicians, 
5 pharmacists, and nurses, in an interdisciplinary approach to patient care. 

Overall System 

Turning to FIGURE 3, the patient care system 100 can include a plurality of medical 
devices 120. In one embodiment, the medical device is an infusion pump 120. Further, in 
another embodiment the medical device is a controller for an infusion pump. For ease of 

10 reference, this disclosure will generally identify the medical device of the system as an infusion 

pump, however, it is understood that the overall system 100 may incorporate any one or more of 
a variety of medical devices. Accordingly, as shown in FIGURE 3, a plurality of infusion 
pumps 120 are connected to a hub or interface 107. As explained in detail further herein, the 
infusion pumps 120 can be of conventional design wherein each infusion pump 120 is associated 

15 with a patient. However, as will be appreciated by those having ordinary skill in the art, the 

infusion pumps 120 shown in FIGURE 3 do not have to be associated with the same patient or 
treatment location even though the infusion pumps are connected to the same hub 107. 
Moreover, each infusion pump 120 can be a single channel pump or a multiple channel pump, 
such as a triple channel pump. Typically, the pumps transmit messages containing pump status 

2 0 information on a periodic basis to the hub 107. A separate hub 107 can be used apart from the 

medical device 120 in order to centralize communications, for cost efficiencies, and/or to allow 
for retrofitting of existing medical devices that do not currently communicate with a central 
computer system 108 so that each such medical device can communicate with a central 
computer system 108. 

2 5 Communication Hubs of the Overall System 

In an embodiment, the serial port or other I/O port of the infusion pumps 120 is 
connected to the hub 107 using a conventional non-wireless transmission medium 105 such as 
twisted-pair wire, coaxial cable, fiber optic cable, or the like. Preferably, the hub 107 can 
connect to a plurality of infusion pumps 120 or just a single pump, through a one-way serial 

30 communications link 105. The hub 107 provides for receiving signals from the connected 

pumps and regenerating the received signals. In particular, the received signals from the pumps 
120 are converted by the hub 107 into a format suitable for transmission onto the system 
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network 102 via wireless communication path or link 128 and cable communication system 1 10. 
Typically, the hub 107 sends pump data to the system network 102. The hub 107 may also filter 
incoming information from the pumps 120 to reject duplicate messages. Additionally, the hub 
107 allows pump status information to be viewed remotely on a clinician's 116 digital assistant 
118. Typically, the hub 107 sends pump data whenever the hub 107 is connected to the pump 
120 and both the hub 107 and the pump 120 are turned on. As explained in detail herein, the 
hub 107 also provides for allowing comparisons of pharmacy-entered orders to the pump 
settings. In a preferred embodiment, the hub 107 is connected to the IV pole holding the pumps 
120, or the hub 107 is incorporated into the infusion pump 120 to create an integrated 
medical/communications device as identified above. 

One embodiment of a hub 107 is shown in FIGURE 47. In this embodiment, the hub 
107 includes pump port indicators 411 for up to 4 pumps, a loss of wireless signal indicator 413, 
a low battery indicator 415, an alert mute key 417, an on/off key and indicator 419, and a 
charging indicator 421. The pump port indicators 41 1 provide a status indicator for each of the 
hub's 107 pump ports. The indicator light shows that the corresponding pump port is properly 
communicating with the network 102. When the indicator light is not lit, however, this indicates 
that the corresponding pump port is not connected to the pump 120 or the port is not 
communicating from the pump 120 to the network 102. The loss of wireless signal indicator 
413 indicates that the hub 107 cannot communicate with the network 102 over the wireless link. 
If a loss of wireless signal occurs, each of the pump port indicators 411 will also turn off, 
indicating that the hub 107 is not communicating with the network 102. If a loss of wireless 
signal occurs, the hub 107 will communicate this event to the system network 102 and the 
central computer system 108 and server 109 for eventual transmission to the clinician 116. The 
alert mute key 417 allows the clinician 1 16 to temporarily silence all audible alerts from the hub 
107. Alternate embodiments of the communications hub include a single dedicated wireless 
module physically within the pump, or a separate module using wireless communications to 
reach both the pump and server. 

Additionally, in an alternate embodiment, the hub 107 may be optionally 
incorporated into the infusion pump 120 to create an integrated medical/communications device. 
The combination hub/medical device would still function identically with respect to each other. 

Access Points of the Overall System 

As shown in FIGURE 3, a plurality of access points 1 14 within the healthcare facility 
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provides an interface between the wireless communication paths and the cable communication 
system. Preferably, when the system network 102 is unavailable, the hub 107 stores the signals 
received from the pumps 120, and then transmits the converted signals to the system network 

102 once the system network becomes available. In a preferred embodiment, communication 
between the hub 107 and the access points 114 is unidirectional from the hub 107 to the access 
point 114 and ultimately the network 102. As such, in the present embodiment the infusion 
pumps 120 can transmit data to the network 102; however, the network 102 cannot transmit data 
to the infusion pumps 120. It is understood, however, that in alternate embodiments also 
disclosed herein, communication between the hub 107 and the access points 114 is bidirectional. 
Accordingly, in these embodiments data and other information may be transmitted from the 
network 102 to the infusion pumps 120. In either case, the information transmitted between the 
network 102 and the hubs 107 is encoded for security purposes. 

Central System Servers/ Computers of the Overall System 

Referring now to FIGURES 1 and 3, the central system 108 can include one or more 
servers or computers. While this disclosure refers generally to servers 109, 108a, it is 
understood that these components may be non-server computers. Preferably, but not 
necessarily, the central system 108 can include a first central server or computer 109 and a 
second central server or computer 108a. In one embodiment, a separate communication system 

103 may be provided for communication between the first central server 109 and the second 
central server 108a. In a preferred embodiment, the separate communication system 103 is an 
isolated point-to-point cable communication Ethernet network. Because this communication 
system 103 is an isolated point-to-point system connection, the data communicated between the 
two servers 109, 108a is typically not encrypted. Typically, the communication system between 
the two servers 109 and 108a allows for bi-directional communication. 

As explained in detail herein, the first central server or computer 109 has a first database 
and a first functional feature set associated to data and functions related to the medical device 
and the user interface. The medical devices 120 and user interface 118 generally communicate 
directly with the first central computer 109. Further, as explained in detail herein, the second 
central server or computer 108a has a second database and a second functional feature set. The 
first central computer 109 is securely connected to the second computer 108a, and the medical 
devices 120 and user interfaces 118 do not communicate directly with the second central 
computer 108a. The user interface 118 can receive data from the second database relating to the 
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second functional feature set of the second central computer 108a through the first central 
computer 109. 

The second central server 108a, and its software sub-system, typically interface with a 
pharmacy system to provide information on drugs, patients and to provide the nurses and other 
clinicians with a typical workflow. The second central server 108a also interfaces with the first 
central server 109 to provide information on patients, nurses, clinicians, orders and associations 
between digital assistants 118 and clinicians. Some of the other functions of the second central 
server 108a can include patient management, item management, facility management, 
messaging, reporting/graphing, and various interfaces to other systems. 

In particular, patient management refers to the general information about each patient 
that comes into a hospital or facility. This information is maintained along with information 
specific to each visit, and generally includes demographics, allergies, admission date, discharge 
date, initial diagnosis, room, bed, etc. Additionally, information about each of the medications 
which have been prescribed, scheduled, and administered is maintained by the second central 
server 108a. Functionality of the patient management function also includes prior adverse 
reaction checking, drug interaction checking, duplicate therapy checking, dose checking and 
drug-disease contraindications. 

Item management refers to the information about each drug that is available in the 
facility. This information is managed and maintained within the second central server 108a. 
Such information includes drug name, strength, therapeutic classification, manufacturer, etc. 
Further, the second central server 108a maintains a perpetual inventory of the item contents of 
the medication depots and other smart storage locations on a real-time basis. The second central 
server 108a assists in providing for updates to be made as the depot is replenished and as doses 
are administered or disposed. 

Facility management refers to the information that describes the overall facility. This 
information is managed and maintained within the second central server 108a of the system 210. 
This information includes: a physical breakdown of the facility into buildings, floors, units, 
rooms and beds; a list of programs and services that are offered and where they are offered; an 
identification of storage units where drug and supply items are stored and the locations they are 
intended to serve. 

Messaging refers to the functionality of the second central server 108a, wherein the 
second central server 108a provides a communications link between the pharmacists and the 
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clinicians. The second central server 108a allows for standardization of dosage and special 
administration instructions, and automatically sends notification of missing doses. Reporting and 
graphing refers to the availability of a number of operational and management reports which can 
be run on request or on a scheduled basis by authorized users of the system 210. 
5 The second central server 108a also has various interfaces, such as: an ADT interface, a 

billing interface, a discrete results interface, a documents results interface, a formulary interface, 
a pharmacy orders interface, a Point of Care medication management interface and an inventory 
interface. These interfaces are explained in greater detail infra, however, a brief explanation is 
provided immediately below. The ADT interface refers to the facilities admission, transfer and 

10 discharge system (ADT). This system typically also operates the registration of pre-admittance 

and outpatients. The discrete results interface refers to an interface with laboratory results. 
Generally, after the lab results and ancillary orders are entered into an external lab information 
system, the discrete results interface or lab interface within the HL7 engine transfers this data to 
the second central server 108a. Once the lab results are saved in the second central server 108a, 

15 a user can view them from the handheld device 118, the Computerized Physician Order Entry 

(CPOE) system, and the second central computer 108a main application. Lab interfaces are 
available for at least four interfaces: radiology lab interface, microbiology lab interface, 
biochemistry lab interface, and pathology lab interface. These interfaces can be configured to 
operate either on four different ports or on the same port. The document results interface 

20 generally refers to the second central server 108a accepting radiology and pathology reports. 

The formulary interface generally refers to the second central server 108a being able to accept 
master file notifications to synchronize an external systems drug file. Changes to a formulary 
will trigger an outbound transaction from the server 108a to an external third-party system. The 
pharmacy orders interface provides for allowing medication orders to be sent to external third- 

25 party systems. The inventory interface provides for accepting pharmacy inventory changes from 

external third-party systems. Additionally, cart depot interfaces are available with the present 
system 100. The second central server 108a stores order and drug file changes in the server 
database, which then sends this information to any third-party cart interfaces. The third-party 
cart interface within the HL7 engine processes this information into HL7 MFN and RDE 

30 messages. The MFN message contains the drug file information and the RDE contains the 

patient orders information. The HL7 engine then transmits these messages to the third-party cart 
server. The HL7 engine also receives HL7 formatted DFT messages from the third-party cart 
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server. The DFT message contains billing information for medication administration. The HL7 
engine processes this information and then sends it to the second central server 108a, which can 
then pass this information to a billing application. The billing application may then calculate 
patient charges and invoice the patient. The billing interface refers to an interface with the 
5 patient charging software. The billing interface supports the optional use of billing algorithms to 

calculate charges. The billing interface processes internal transactions, as well as external 
inbound transactions from third-party systems. The billing interface provides an HL7 interface 
between the second central server 108a and the hospital's third-party financial system. The 
billed quantity may be sent directly, or patient charges may be calculated by the billing interface 

10 to send to the hospital's third-party financial system. The information is sent in real-time via 

HL7 messages. The Point of Care interface consists of web service communications which 
integrate information regarding point of care medication management for non-infusion related 
data. These data are communicated in real-time in order that the user interface can integrate 
medication management for infusion related and non-infusion related medications. 

15 Conversely, the first central server 109 has software loaded and configured for sending 

and receiving data to and from multiple hubs 107, multiple digital assistants or user interfaces 
118, and with the second central server 108a. As explained in detail below, the first central 
server 109 may perform several functions, including, but not limited to: comparing prescription 
parameters as received from server 108a to the applicable programmed pump settings received 

20 from the hub 107 system; relaying notifications and messages to the digital assistants 118; 

relaying alarm and alert information received from the hub 107 system to the appropriate digital 
assistant 118; relaying pharmacy and patient information as communicated from the server 108a 
to the appropriate digital assistant 118; and compiling pump status and alarm monitoring data 
and relaying this data to server 108a on a periodic basis. If required, the operations performed 

2 5 by the server 109 are compliant with the Health Insurance Portability Act of 1996 (August 21), 

Public Law 104-191. Typically, the data resident in the first central computer or server 109 is 
an intersection with the data resident in the second central computer or server 108a. Server 109 
contains a subset of the data contained in server 108a that is required to perform its 
functionality. Server 109 also contains data relating to the system network 102, hubs 107 and 

30 infusion pumps 120 that are required to perform its functionality. As explained above, such data 

is generally that data required for the functions or performance of the digital assistants 118 and 
medical devices 120. 
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In one embodiment, a cost-effective integration pf-medical devices 120 or other devices 
and functionality with the hospital information systems in the first and second central computers 
109, 108a is provided by isolating a subset of the total data mentioned above, such as patient 
safety-specific information, and locating such information and functionality in a 
5 validated/verified part of the system. In this context, an FDA regulatory context, verified means 

providing objective evidence that all requirements are tested and validated means providing 
objective evidence that the product meets customer needs. In the present embodiment, the 
validated part of the system is located within the first central computer 109. In one embodiment, 
the subset can include infusion pump generated alarms and/or alerts and/or medical device 120 / 

10 infusion pump 120 / controller 120 programming or operating parameter information. This 

subset is isolated and located in the validated part of the system, within the first central computer 
109, and the remaining portion of the overall data is maintained in the database in the non- 
validated portion of the system, within the second central computer 108a. The validated 
database located at the first central computer 109 and non- validated database located at the 

15 second central computer 108a are kept in sync using Web services replication, as will be better 

understood by one of ordinary skill in the art from the details provided below. An alternate 
embodiment may include both the validated and unvalidated portions of the system residing on a 
single computer and functionally separated by means of a software firewall (e.g., operating 
system features or other OTS software). As will be described below, the "syncing" may be 

2 0 performed periodically based on time intervals, other predetermined times, and/or as needed 

when important data, such as patient registration status, changes occur. At intervals, a fresh new 
copy of the replicated data is sent to the other central computer, and validated first central 
computer 109 replaces its local copy with the new copy. When critical information changes, the 
change is propagated immediately to the validated first central computer 109 and processed as a 

2 5 change rather than as a replacement of the existing information. Thus, a portion or all of the 

subset located at the database at the first central computer 109 also exists at the second central 
computer 108a, as will be understood from the details provided herein. This process will be 
better understood with reference to the details provided below. Thus, by localizing a subset of 
the database, such as the patient safety-specific data at the first central computer, at least the cost 

30 of system development is further optimized, and integration with third-party non-validated 

systems and the respective data and information therein is made more time and cost effective. 

In one embodiment, the first central computer 109 can comprise a validated server, such 
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as a Compaq DLG-380 with Windows 2003 Server OS, running Active Directory for user and 
device authentication, Certificate Authority for issuance of server and client certificates, SQL 
Server 2000 for temporary data storage, Internet Information Server (IIS) for application hosting 
(Web Services and Web pages). The second central computer 108a can comprise a non- 
5 validated Server, such as an external Hospital Information System (HIS) Server connected 

through a dedicated Ethernet TCP/IP connection 103 accessing a data replication Web service 
exposed by the validated server at the other end of the dedicated connection. The second central 
computer 108a can alternatively comprise software for performing one or more of the various 
functionalities described in general herein, such as a pharmacy and other systems. Thus, the 
10 second central computer can comprise these types of functions and have an interface with other 

systems, such as an external Hospital Information System (HIS) Server. 

The first central computer (i.e., server 109) includes a database containing a data storage 
package or first database. In an embodiment, the first database can be external or internal to the 
first central computer 109, but preferably is only accessible to users of the application 5412 , as 

15 shown in FIGURE 54, loaded on the first central computer. The data tables within the first 

database are used within the use cases described further herein. Preferably, the data tables 
include tables related to medical devices, digital assistants, hubs, patients, clinician, 
prescriptions, titration, comparison information, alarms, and escalations. Moreover, medical 
device tables can include tables related to pump, pump channel, pump sub-channel. Also, alarm 

2 0 tables can include tables related to hub alarms, pump alarms, channel alarms, an alarm history 

log, and the like. 

In an embodiment, each table can include a key wherein data within the table is 
responsive to the key. For example, a key to a table regarding a pump channel information log 
can be a pump channel log identification wherein, in response to the key, table data is provided 
25 regarding the channel identification, pump rate, dose mode, dose, volume remaining, primary 

volume infused, and the like. Moreover, the tables can be linked. For instance, a patient table 
having patient information can be linked to a clinician table which can be linked to a digital 
assistant table. 

The patient care system 100 of FIGURE 3 can be divided into a hub subsystem, a first 
30 central computer or server subsystem, a medical device or pump subsystem, a second central 

computer or server subsystem, and a personal digital assistant (PDA) subsystem. The hub 
subsystem and the first central computer subsystem are discussed in detail further herein. 
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Turning to the medical device subsystem, this subsystem preferably includes one or more 
medical devices 120 such as infusion devices for allowing delivery of medication to a patient 
wherein status and infusion information for each infusion device is transmitted periodically from 
a communication port associated with each device. 

Generally, the second central computer subsystem is a server 108a having computer 
hardware and software for interfacing with a pharmacy system to provide information regarding 
drugs, patients, and typical nurse workflows. The server 108a can also have various other 
applications as previously discussed herein, such as an interface to a Hospital Information 
System (HIS). Preferably, the second central computer interfaces with the first central computer 
subsystem to provide the first central computer with information regarding patients, nurses, 
orders, and the association between a personal digital assistant and a nurse or clinician. 

In one embodiment, a central computer has at least two environments: a validated 
environment and a non-validated environment. The validated environment may have a first 
operating system with a set of applications and a first database. The first database may have a 
first functional feature set associated with certain data therein. In one embodiment, this 
functional feature set has functions related to the medical device and the user interface for the 
medical device. The medical device and user interface communicate directly and securely with 
the validated environment. The non-validated environment may have a second operating system 
with a set of applications and a second database. The second database may have a second 
functional feature set associated with certain data therein. Typically, there is a logical 
separation between the validated environment and the non-validated environment. The user 
interface can receive data from the non-validation portion of the database relating to the second 
functional feature through validation portion of the system. In one embodiment, the validation 
portion is separated from the non-validation portion by a logical separation or fire wall, which 
may be implemented in software. Various software, such as VMware and Virtual PC, are 
examples of emulation software that emulates multiple environments on the same server. In 
another embodiment, the validation portion may be on the first central computer 109, and the 
non-validation portion may be on the second central computer 108a. In another embodiment, 
the central computer comprises a first server and a second separate server. The first and second 
servers are separated by a fire wall, and the central validation portion of the central computer 
resides in the first server, and the second non-validation portion of the central computer resides 
on the second server. 
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Preferably, as explained in detail elsewhere herein, the personal digital assistant 
subsystem includes one or more small portable devices 118 that provide clinicians and nurses 
116 (FIGURE 1) with remote information regarding: their patients; the status of infusions 
including the relay of alarms and alerts information; and infusion comparison results. As 
5 discussed herein, the first central computer is operably connected to one or more personal digital 

assistants 118 within the PDA subsystem. In an embodiment, the personal digital assistants are 
WINDOWS CE.NET based and used as a clinician terminal device. In particular, the personal 
digital assistant can be operably connected to the first central computer through a secure PKI- 
authenticated wireless LAN (802. Ix) connection, as explained in more detail herein. 
10 The hub subsystem preferably includes components such as one or more hubs 107 for 

receiving data from the medical devices 120, transmitting the pump data to the first central 
computer subsystem 109, and detecting conditions that can effect data communications with one 
or more hubs. 

As indicated previously, in an embodiment, a hub 107 within the hub subsystem 
15 interfaces with up to four infusion devices 120 through a one-way serial communications link 

105 wherein the infusion devices transmit messages (i.e., packets of data) containing pump 
status information on a periodic basis to the hub. Alternatively, the packets can be transmitted 
based on user defined criteria such as regular time intervals, event occurrences, a combination of 
time intervals and event occurrences, or the like. 
20 Each hub 107 within the hub subsystem filters incoming information to reject duplicate 

messages, stores, and then forwards the pump information to the first central computer 
subsystem utilizing, in an embodiment, a built-in wireless network transceiver. In an 
embodiment, the pump information is not forwarded unless the data received from the medical 
device has changed. 

25 The transceiver built into a hub 107 routes the outgoing information to a wireless access 

point 114 which in turn routes it to the first central computer 109 using the wired Ethernet 
subsystem 1 10. This outgoing information preferably contains XML encoded data formatted as 
SOAP messages specifically designed to be received by a web services type of software 
interface. 

30 As will be appreciated by those having ordinary skill in the art, the term "XML" refers to 

a system for organizing and tagging elements of web documents wherein, with XML, 
customized tags can be created for enabling the definition, transmission, validation, and 
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interpretation of data between applications and between systems or subsystems. Moreover, as 
used herein, the term "web services" refers to integrating web-based services using XML and 
SOAP wherein the term "SOAP" is a messaging protocol used to encode the information in web 
service request messages and response messages before sending them over the network or 
5 communication path. 

The first central computer subsystem preferably consists of a server 109 with a software 
application loaded and configured for sending and receiving data to and from multiple hubs 107, 
multiple digital assistants 118, and the second central computer sub-system comprising server 
108a. 

10 Turning to FIGURE 54, server 109 is preferably a COMPAQ DLG-380 with a 

MICROSOFT WINDOWS 2003 Server operating system 5414. In one embodiment, software 
components that are loaded within the memory of the first central computer 109 include a first 
central computer or server application 5412 within a .NET Framework 5416, an Active 
Directory Domain Service 5418 for users and device authentication, an SQL Server 5420 (show 

15 as a database) for temporary data storage, and Internet Information Server 5422 (IIS) for 

application hosting. The .NET Framework 5416 is preferably Microsoft .NET Framework 1.1 
or greater wherein the .NET Framework connects the first central computer application 5412 to 
the operating system, Internet Information Server 5422, SQL Database 5420, and Active 
Directory Domain Service 5418 components. As will be appreciated by those having ordinary 

20 skill in the art, the Active Directory Domain Service 5418 provides services utilized by the 

Windows Server Operating System 5414 and the first central computer application 5412 to 
assist in ensuring that only authentic and authorized hub subsystem, second central computer 
subsystem and users of the personal digital assistant subsystem have access to the first central 
computer and thus the first central computer application 5412. 

2 5 In an embodiment, the first central computer (i.e., server 109 of FIGURE 3) performs 

several functions that include: 1) comparison of the prescription parameters as received from the 
second central computer subsystem to the applicable programmed pump setting received from 
the hub subsystem and/or program the pump; 2) relay of alarm and alert information received 
from the hub subsystem to the appropriate personal digital assistant 118 (FIGURE 3); 3) 

30 provision of pump status and flow rate history information to the appropriate personal digital 

assistant 118; 4) relay of pharmacy and patient information as communicated from the second 
central computer 108a (FIGURE 3) to the appropriate personal digital assistant 118; and, 5) 
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compilation of pump and alarm monitoring data and relaying of this data to the second central 
computer 108a on a periodic basis. 

The first central computer preferably includes a plurality of external software component 
interfaces. In an embodiment, three of these interfaces can be classified as "incoming 
interfaces" that receive incoming HTTP request messages and then issue outgoing HTTP 
response messages. The remaining two interfaces can be classified as "outgoing interfaces" that 
either send HTTP request messages or XML formatted response messages as explained below. 
As used herein, the five software interfaces are referred to as the DatabaseRefreshListener 
incoming and outgoing interfaces, the RoutePDA incoming and outgoing interfaces, and the 
PumpDataListener incoming interface. 

In an embodiment, four of the external software component interfaces are paired to 
create two distinct bi-directional communication channels between the first central computer 
109 and the second central computer 108a of FIGURE 3. The first channel includes both the 
DatabaseRefreshListener incoming and outgoing interfaces paired together. Accordingly, the 
first channel is referred to herein as "DatabaseRefreshListener," and is utilized by the second 
central computer 108a for periodic synchronization of data in its database tables with data 
located in the first central computer's database tables. 

Using the DatabaseRefreshListener channel, the second central computer 108a updates 
the first central computer's database tables by sending XML encoded data formatted as SOAP 
messages to the first central computer's web services type of interface. Similarly, the second 
central computer 108a updates its own database table by sending XML encoded requests for 
data to the first central computer's web services type of interface which in turn triggers the first 
central computer 109 to respond with XML encoded data. 

As indicated above, the incoming interface portion of the DatabaseRefreshListener 
channel is utilized by the second central computer for updating of database tables located in the 
first central computer with data from second central computer's database tables. Moreover, the 
outgoing portion of the DatabaseRefreshListener channel is utilized by the second central 
computer for updating its own database with data from the first central computer's database 
tables. 

Preferably, the DatabaseRefreshListener incoming interface contains several web service 
methods named "RefreshXXX" where "XXX" corresponds to the type of data being transferred. 
In an embodiment, these methods receive incoming HTTP request messages containing XML 
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encoded data formatted per the SOAP protocol. The XML encoded data is structure in a form 
that corresponds to rows in a database table. For example, the method "RefreshUsers" receives 
data structures consisting of pairs of user names and user passwords corresponding to rows in a 
database table that contains user name and user password columns. 
5 As shown in FIGURE 54, the incoming messages are routed via the Internet Information 

Server and the .NET Framework components to the application 5412 loaded on the first central 
computer (i.e., server 109 of FIGURE 3). The first central computer application 5412 utilizes 
the Active Directory Domain Service 5418 to verify that the second central computer message is 
authentic, processes the contents, and then stores the resulting data in the SQL server database 

10 component 5420. 

The application 5412 loaded on the first central computer then responds to the second 
central computer by issuing an HTTP response method that is routed via the .NET Framework 
component 5416 and internet information server component 5422 to the second central 
computer. This response message indicates the success or failure of the data transfer and 

15 processing. 

Preferably, the DatabaseRefreshListener incoming interface is asynchronous in nature, 
thus decoupling the second central computer from the first central computer to the extent 
practical. This decoupling allows the second central computer to be programmed for continued 
data processing while waiting for responses and for responding to losses in communication in a 
20 manner that is under program control. Moreover, the DatabaseRefreshListener incoming 

interface can also contain a web method for use by the second central computer to periodically 
signal the first central computer that the second central computer is functioning. 

In contrast to the DatabaseRefreshListener incoming interface, the 
DatabaseRefreshListener outgoing interface is utilized by the second central computer for 

2 5 updating its own database with data from the first central computer's database tables. To ensure 

that the data has been captured by the second central computer before permanent removal from 
the first central computer, DatabaseRefreshListener outgoing interface utilizes a multi-step 
approach for data transfer as follows: 1) The second central computer checks for the availability 
of the data; 2) The second central computer requests that the first central computer send the 

3 0 data; 3) the second central computer confirms that the data has been received; 4) the second 

central computer confirms that the data has been correctly stored in its database tables. 

To check for the availability of data, the second central computer first sends to the 
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applicable web method of the DatabaseRefreshListener outgoing interface is an XML encoded 
request message formatted per the SOAP protocol. Preferably, the specific web method utilized 
is of the form "BeginGetXXXTo Archive" wherein "XXX" corresponds to the type of data 
being requested. For example, the method "BeginGetChannelDataToArchive" request the 
5 availability of time stamped pump channel records received by the first central computer from 

the pumps through the hub subsystem. 

The request message is passed through the Internet Information Server component 5422 
and .NET Framework component 5416 to the application loaded within the first central 
computer. The application 5412 loaded within the first central computer decodes the XML 
10 contained in the request message to determine what data is being requested by the second 

central computer. 

The application 5412 loaded within the first central computer checks for the availability 
of the requested data in the SQL Server Database 5420. If the data is available, the application 
prepares an XML encoded response message indicating that data is available. If the data cannot 
15 be obtained, the application 5412 prepares an XML encoded response message indicating that 

data is not available. 

If the data is not available, the second central computer may retry or proceed with a 
different transfer consistent with its processing rules. 

If the data is available, the second central computer initiates the data transfer by sending 
2 0 to the applicable web method of DatabaseRefreshListener outgoing interface a second XML 

encoded request message. Preferably, the specific web method utilized is of the form 
"EndGetXXXToAcrchive" wherein "XXX" is identical to that used above. 

The application 5412 within the first central computer decodes the XML contained in the 
request message to determine what data to return to the second central computer and places the 
2 5 data in an appropriate XML encoded response message structured in a form that corresponds to 

rows in a database table consistent with the approach utilized by the corresponding incoming 
interface. 

In an embodiment, the data is routed to the second central computer via the .NET 
Framework component 5416 and Internet Information Server component 5422. If the data was 
30 not correctly received, the second central computer may retry or proceed with a different 

transfer consistent with its processing rules. 

If the data was received correctly, the second central computer then sends a third request 
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message to the applicable web method of this interface. Preferably, the specific web method 
utilized is of the form "BeginDeleteArchivedXXX" where "XXX" is identical to that used 
above. 

Upon receipt of this message, the application 5412 loaded within the first central 
5 computer marks the relevant data in the SQL Server Database component as being sent to the 

second central computer for archiving and issues a response message acknowledging that the 
data has been marked. 

To signal the success or failure of storing the data in the second central computer 
database, the second central computer sends a fourth request message to the applicable web 
10 method of this interface. The specific web method utilized is of the form 

"EndDeleteArchivedXXX" where "XXX" is identical to that used above. 

If the second central computer indicates that the transfer was unsuccessful or if sufficient 
time has elapsed that the first central computer determines that a loss of communication has 
occurred, then the relevant data is retained in the first central computer database for further 
15 transfer as requested by the second central computer. 

If the second central computer indicates that the transfer was successful, then the 
archived data is purged from the first central computer database and the application 5412 loaded 
within the first central computer issues a response message confirming completion of the final 
step of this transfer. 

20 Preferably, the DatabaseRefreshListener outgoing interface is asynchronous in nature, 

thus decoupling the second central computer database from the first central computer to the 
extent practical. 

The second bi-directional channel between the first central computer 109 and the second 
central computer 108a is referred to herein as "RoutePDA" and includes both the RoutePDA 

2 5 incoming and outgoing interfaces paired together. The RoutePDA channel is used by the first 

central computer 109 for routing of HTTP request messages originating from the PDA 
subsystem to the second central computer 108a, then receiving the corresponding HTTP 
response messages from the second central computer, processing if applicable, and then routing 
back to the originating personal digital assistant 118. 

3 0 In the second channel (i.e., RoutePDA), messages received from or sent to a personal 

digital assistant 1 18 are preferably transmitted to and from the first central computer 109 via the 
hospital or healthcare facility's wired Ethernet system 110, a wireless access point 114, an a 
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wireless transceiver built-into each personal digital assistant 118. 

Preferably, HTTP request messages are forwarded without processing through the first 
central computer 109 to the second central computer 108a. The second central computer 108a 
then issues HTTP response messages containing either XML or HTML formatted information. 
5 HTML formatted response messages are routed through the first central computer 109 to the 

personal digital assistant 118 without further handling. 

XML formatted response messages are used by the second central computer 108a to 
signal to the first central computer 109 that the user 116 (FIGURE 1) has requested a web page 
that the first central computer 109 creates, such as a prescription comparison results page or a 

10 pump-monitoring page. The first central computer 109 examines the XML response, processes 

as appropriate, and issues an HTML or XML formatted response message to the sending 
personal digital assistant 118. 

As indicated previously, the RoutePDA channel is used by the first central computer for 
routing of HTTP request message received from the PDA(s) 1 18 to the second central computer 

15 and then receiving the corresponding HTTP responses returned by the second central computer, 

processing if applicable, and then routing back to the sending PDA(s). 

Accordingly, the RoutePDA incoming interface is utilized for communication with the 
web browser located in the PDA(s) 118. This interface receives incoming HTTP request 
messages containing data encoded as name-value pairs consistent with the HTTP "GET" and 

20 "POST" protocols. The incoming messages are routed via the Internet Information Server and 

the .NET Framework component to the application 5412 loaded within the first central 
computer. The application 5412 loaded on the first central computer reroutes the incoming 
message to the second central computer utilizing the .NET Framework 5416 and the RoutePDA 
outgoing interface as discussed below. 

25 When an HTTP response is received at the RoutePDA outgoing interface, the application 

5412 loaded on the first central computer determines whether the response utilizes HTHL or 
XML formatting. HTML formatted responses are rerouted by the first central computer to the 
PDA without further handling, via the .NET Framework component 5416 and Internet 
Information Server component 5422. 

30 XML formatted responses, however, are used by the second central computer to signal to 

the first central computer that the user has requested a web page that the first central computer 
creates, such as a prescription comparison results page or a pump-monitoring page. The first 
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central computer examines the XML response from the second central computer, processes as 
appropriate, and issues an HTML or XML formatted response to the appropriate PDA(s), via the 
.NET Framework and Internet Information Server components. Preferably, the RoutePDA 
interface is synchronous in nature due to the inherent synchronous behavior of the web browsers 
contained in the PDAs. 

In contrast to the RoutePDA incoming interface, the RoutePDA outgoing interface is 
utilized for routing HTTP request messages received by the application 5412 loaded on the first 
central computer from the personal digital assistant subsystem to the second central computer 
for processing and then receiving the corresponding HTTP response sent by the second central 
computer in return. 

In both the DatabaseRefreshListener channel and the RoutePDA channel, the first central 
computer 109 sends and receives information from the second central computer 108a through an 
isolated point-to-point Ethernet sub-system 103 that is preferably dedicated to this use only. 

As indicated above, in utilizing the DatabaseRefreshListener channel, the first central 
computer exposes a specialized Web service on the dedicated link 103 that is used by the second 
central computer to replicate new and updated database information (such as patient 
information, clinician information, pharmacy information, and the like) periodically and as 
needed to the first central computer. Also, data is provided from the second central computer to 
the first central computer. 

Moreover, in utilizing the RoutePDA channel at the clinician terminal device end, the 
first central computer 109 exposes a NET IIS Server interface serving HTTP-style web pages 
and maintaining authenticated web session with the PDA devices 118. Stated another way, the 
clinician terminal device (i.e., personal digital assistant 118) receives authenticated web pages 
from the first central computer 109. 

At the first central computer end of the dedicated connection 103 to the second central 
computer, the first central computer establishes a virtual HTTP session for each PDA device 
118 connected to the first central computer, and impersonates a Web browser to the second 
central computer relaying HTTP request from the PDAs as they are being received by the first 
central computer. Stated another way, the first central computer, through the dedicated 
connection 103 to the second central computer, relays requests requiring non- validation to the 
second central computer. 

Accordingly, when the information flow between a PDA 118 and the server system 
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requires information originating from the second central computer side or merged information 
be presented, the second central computer posts an XML SOAP packet to the Web service 
exposed by the first central computer on the dedicated link 103 and the first central computer 
uses the XML data to perform a merger operation with the information originating from the first 
5 central computer side of the system, converts the result to HTML, and then posts the HTML 

back to the clinician's PDA device 118. 

The fifth external software component interface, referred to as PumpDataListener is an 
incoming interface for communication with the hub subsystem, as explained in more detail 
herein. In an embodiment, the PumpDataListener interface does not have a corresponding 

10 outgoing interface because the transfer of pump data is one-way, only, except for 

communication verification. However, in an alternative embodiment, an outgoing interface can 
be provided for transfer of pump command and control data to the medical devices 120. 

The PumpDataListener incoming interface is utilized for receipt of data from the hub 
subsystem. Preferably, this interface contains a single web service method referred to as 

15 "SendPumpData." This method receives incoming HTTP request messages containing XML 

encoded data formatted per the SOAP protocol. The XML encoded data is structured in a 
hierarchical form such that data from several pumps and several channels per pump at several 
different times can be combined into a single large message structure. 

The incoming messages are routed via the Internet Information Server and the .NET 

2 0 Framework components to the application 5412 loaded within the first central computer 

application. The first central computer application utilizes the Active Directory Domain Service 
component to verify that the hub subsystem message is authentic. The first central computer 
then processes the contents, and stores the resulting data in the SQL Server Database 
component. Finally, the first central computer application issues an HTTP response message to 

2 5 the sending hub device via the .NET Framework and Internet Information Server components. 

This response messages indicated the success or failure of data transfer and processing. 

Data packets received by the first central computer (i.e., server 109) from the hubs 107 
are preferably stored within the first central database of the first central computer. Preferably, if 
an alarm or alert event is included in the packet, the first central computer can immediately 

30 dispatch the event to the appropriate clinician(s) via his or her digital assistant 118, or 

alternatively, the first central computer can enter the event into the first central computer 
database and later dispatch the information when requested by the appropriate clinician(s) via 
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his or her digital assistant. As indicated previously, the first central computer 109 maintains a 
log of all clinicians that are logged onto his or her digital assistant 118 which is authenticated 
every time the clinician logs onto the system. 

Preferably, the PumpDataListener incoming interface is asynchronous in nature, thus 
decoupling the hub subsystem from the first central computer subsystem to the extent practical. 
The decoupling allows the hubs 107 within the hub subsystem to be programmed for continued 
data processing while waiting for responses and for responding to losses in communication in a 
manner that is under program control. Nonetheless, the PumpDataListener maintains a 
"heartbeat" to monitor (lack of) continuity of communications between all wireless modules 
and/or remote pump devices and the central computer. 
Communication With Clinician Handheld Devices 

As described in detail further herein, pump status, alerts, alarms, patient information, 
chart information, comparison information, to-do lists and other data/information are provided to 
clinicians via a personal digital assistant or user interface 118 having a display 118a and, if 
desired, an audible tone or sound generator (not shown). The digital assistant 118 
communicates with the central system 108 via the central network 102 and, in particular, 
wireless communication path or link 126 and cable communication system 110. As stated 
previously, one or more wireless access points 114 provide an interface, in a conventional 
manner, between the wireless communication paths and the cable communication system. The 
digital assistant 118 may receive messages from both servers 109 and 108a. 

Preferably, communication between the central system 108 and the digital assistant 118 
is bidirectional. Moreover, it is desired that the digital assistant 118 include enough memory 
and processing capability to store and execute a module or application (not shown) for testing 
the integrity of the communication link between the digital assistant and the central system 108 
or the wireless access point 1 14. 

Preferably, but not necessarily, a module or application installed on the digital assistant 
118 is a script or other computer instructions (i.e., software code) written in a high-level 
programming language, such as JAVA, that can be executed with or without clinician 
intervention. The script can be automatically downloaded from the server 108a or 109 to the 
digital assistant 118, or to the medical device 120, as a receiver function of the system. As an 
example, one type of script that may be automatically downloaded from the server to the digital 
assistant is a script that tests the integrity of the communication link by periodically polling, or 
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monitoring communication, including notifications and messaging, from the central system 108 
or the access point 114. In a preferred embodiment, the script running on the digital assistant 
polls the system 108 approximately every 3 seconds. If a response is not received from the 
central system 108 or the access point 114, the module or application installed on the digital 
5 assistant 118 generates a time-out that results in audible tones and/or a notification on the visual 

display 118a that communication with the central system 108 has been lost. The notification on 
the visual display 118a can be, for example: the activation of an information pop-up window 
stating that the communication link is lost, or the changing of an active icon display on the 
visual display 1 18a. As used herein, and recognized by those having ordinary skill in the art, a 

10 time-out is an output generated by a module or application for indicating that the module or 

application has waited a certain amount of time for input, but has not received it. Another type 
of script may poll to determine if an alarm or alert has been triggered. Numerous other scripts 
may be running simultaneously. One advantage of running scripts that are downloaded from the 
system to the digital assistant is that there is no need to install custom code on each digital 

15 assistant 118. If any event (i.e., a message, notification, alarm, alert, etc.) is present, the digital 

assistant 118 automatically retrieves the event from the server and displays it on an interface 
screen of the digital assistant 118. Other added advantages of the script approach are 1) the 
script code can be easily updated at the central server instead of requiring each digital assistant 
to be updated, 2) the scripts can be verified/validated relatively independently of the digital 

2 0 assistant hardware platform because the functionality is hardware independent, thus changes or 

upgrades to the digital assistants have minimal effect on script operation. 

As indicated previously, each clinician preferably has an associated digital assistant 118 
that, in an embodiment, provides the clinician with a view of a page consisting of an HTML 
frame set with a dedicated frame for display of events. The dedicated frame can have a JAVA 

2 5 script inserted therein for display of events wherein the script interrogates the first central 

computer 119 for new events such as pump alarms and alerts directed to the digital assistant 
118. If any new events have occurred, then the first central computer provides this information 
to the digital assistant 118 wherein it is displayed within the dedicated frame for display of such 
events. 

30 One type of notification provided on the digital assistant 118 indicates to the clinician 

that data presented by the digital assistant 118 is not current, and access to alerts and alarms is 
not available. Conversely, the digital assistant 118 can also indicate when the digital assistant 
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1 18 is linked to the central system 108 for providing real-time access to alerts and alarms. 

Other notifications that are typically communicated via scripts include, but are not 
limited to: pump "silent shut down," overrides of pump infusion limits, end of infusion, 
occlusion trend information, low battery, pre-occlusion indicator, over use of bolus, keep vein 
open alert, stat medication notifications, change orders, lab results, radiology results, updating, 
change in telemetry data and/or vital signs information, doctors or pharmacy attempting to reach 
the nurse, patients that are requesting the nurse, loss of communication, messages from other 
devices, new rate for medical device based on vital information, rate following purge, etc. 

As stated previously, clinicians within a healthcare facility have access to infusion alerts, 
alarms, and messages via the remote wireless device 118 (i.e., also referred to as a personal 
digital assistant (PDA) 118) or other computer devices, wireless or hardwired to the network 
108, such as a tablet computer with a bar code reader operably attached, or a laptop computer 
attached to an IV pole and having a bar code reader operably attached to the computer. 

Preferably, the infusion system 210 provides clinicians and other users with options for 
automating alert event-driven messages. Moreover, healthcare facility administrators and other 
users can customize the types of automated messaging to appear, via the remote wireless device, 
by message type or classification, severity of abnormality, and time-based reminders. 
Additionally, the infusion system provides clinicians and other users with the ability to 
configure audible messages, visual messages, or both. 

The messaging provided by the infusion system 210 preferably includes a user- 
configurable rules engine, a scheduler, and interfaces to infusion pump systems. Moreover, it is 
desired that the results-driven messaging provide clinicians with real-time decision support at 
the point of care via a workstation, electronic tablet, wireless personal digital assistant, or the 
like. 

Generally, the communication between the infusion pump 120 and the network 102 and, 
further, from the network 102 and the clinician's digital device 118 allows the clinician 116 to: 
view electronically-compared pharmacy-entered orders to programmed pump settings and/or 
program the pump, use the system as a method of remotely viewing pump alerts and alarms, 
view the pump status remotely, view notifications and view the history of the infusion setting 
changes, among other things. 
Patient Care System 

Turning back to FIGURE 1, patient care system 100 preferably includes a computerized 



Attorney Docket No. 



(1417G P1047) 



32 

physician order-entry module (CPOE), an inpatient pharmacy module, a wireless nurse charting 
system, and an electronic patient medical record module. In one embodiment, such systems and 
modules are applications of the second central server or second central computer 108a. It is 
desired that patient care system 100 provide a comprehensive patient safety solution for the 
5 delivery of medication. Within patient care system 100, software modules are provided to link 

together existing patient care systems using interfaces such as HL7 interfaces that are known to 
those having ordinary skill in the art. Preferably, the patient care system 100 operates on a 
variety of computers and personal digital-assistant products to transmit orders, update patient 
medical records, and access alerts, alarms, and messages. 

10 The computerized physician order-entry module enables physicians to enter medication 

orders, access alerts, alarms, messages, reminders, vital signs and results. A pharmacy module 
checks the prescribed drug against documented patient allergies, and for compatibility with other 
drugs and food. The pharmacy module also provides real-time data for inventory management. 
A nurse medication-charting module provides clinical information that is immediately available 

15 at the bedside, thus ensuring verification of medication and dosage at the point-of-care. 

Patient care system 100 integrates drug delivery products with the information required 
to assist in ensuring safe and effective delivery of medication. The clinical decision support and 
accompanying alerts, alarms, warnings, and messaging of the patient care system 100 provide a 
safety net of support for clinicians as they deliver patient care under increasing time and cost 

2 0 pressures. This information is preferably supplied through a wireless network that supplies data 

in a way that improves clinician workflow, making delivery of care easier. 
Overview of the Infusion System 

The infusion system 210, or healthcare system 210, within the patient care system 100 
provides computerized prescribing and an electronic medical administration record (eMAR), 

2 5 among other things. Infusion system 210 puts charting, medication history, inventory tracking, 

and messaging at the clinician's fingertips. Patient care system 100 combines bar-coding and 
real-time technology to assist in ensuring that the right patient gets the right medication and the 
right dosage, at the right time, via the right route. Infusion system 210 provides alerts, alarms, 
messages, and reminders such as, but not limited to, lab value, out of range, and missed dose. 

30 As part of the verification of the right dosage, the system can also provide verification of the 

settings of an infusion pump. 

As explained in detail further herein, the infusion system 210 resides, at least in part, on 
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one or more electronic computing devices such as wireless remote personal digital assistants, 
workstations, physician order-entry modules, electronic tablets, processor controlled infusion 
pumps, or the like. The infusion system 210 can be configured to display, via one or more of the 
electronic computing devices, numerous hospital-definable alerts and alarms in varying forms. 
In an embodiment, time-based alerts are provided to remind clinicians to perform a patient care 
function such as, but not necessarily limited to, changing an infusion rate. Further, emergency 
alarms are provided such as, but not necessarily limited to, an infusion being disconnected. 
Moreover, less urgent messages are provided such as, but not necessarily limited to, the infusion 
being completed or the line being occluded. In addition, the infusion status can be viewed from 
anywhere within the healthcare facility via one or more of wireless remote personal digital 
assistants or other electronic computing devices. 

As disclosed in greater detail infra, the system 210 provides for the escalation of alarms 
or alerts that are not indicated as corrected within a predetermined period of time. Conditions 
that can result in the escalation of an alarm or an alert are preferably defined by the health care 
facility. Likewise, the time before an alarm or alert escalates can also be defined by the health 
care facility. Accordingly, predefined alarms or alerts that are not corrected by a clinician 
within a predefined period of time will result in the escalation of the associated alarms or alerts. 
Thus, the frequency that the clinician is notified by the system of the escalated alarms or alerts is 
preferably increased, as can be the volume of the audible tones associated therewith. 

As will be appreciated by those having skill in the art, the infusion system 210 assists in 
ensuring patient safety by checking the infusion being administered with the patient's order. As 
explained in detail further herein, a bar-coding scheme is used wherein the infusion bag and the 
patient ID are scanned. The infusion information is displayed on both an electronic computing 
device and the pump to assist in ensuring that the right infusion is being administered to the right 
patient at the right time, and by the right route and at the right rate. In an embodiment, an alert, 
audible and visual, appears on the electronic device if the above administration "rights" do not 
match. Moreover, through a comparison process described in greater detail infra, when the 
clinician sets the infusion pump rate, an audible and visual alert appears on the electronic 
computing device if the programmed settings do not match the patient's infusion order. In 
addition, at any time the clinician can, via the electronic device, check the settings of an infusion 
pump to confirm if the settings match the infusion order as contained within the central database 
108b. 
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In an embodiment, the infusion system 210 provides alerts and alarms, via one or more 
of the electronic computing devices or the like, with differing tones or phrases for fast 
identification of the severity or urgency of the message. Desirably, conventional infusion pump 
alerts and alarms can be displayed on the electronic computing devices, such as, but not 
5 necessarily limited to, a personal digital assistant, to keep the clinicians informed of the status of 

the infusions for all assigned patients, thereby saving time in resolving problems and improving 
workflow safety. 

All alarms and alerts are preferably retrievable from a central system database for, inter 
alia, reporting purposes. The retrievable data can assist a healthcare facility in examining and 

10 analyzing how many medication errors were avoided through alarms, alerts, and warnings. 

Desirably, the audible alerts and alarms are configured to sound differently according to 
the severity or urgency associated with the message or issue. Alarms requiring immediate 
attention sound different from less emergent alerts. Visual text describing the problem is 
preferably displayed by one or more of the electronic computing devices. In an embodiment, an 

15 alert sounds on a personal digital assistant when an infusion is nearing completion or is 

completed. The personal digital assistant also displays the patient, location, infusion type, and 
the time remaining before the infusion bag is empty. At all times the clinician can access, via 
the personal digital assistant, the status of infusions and thus react accordingly. In an 
embodiment, before visiting a patient room, the clinician can view the status of the infusions on 

2 0 the personal digital assistant to determine whether another bag will be needed in the near future. 

If another infusion bag is needed, the clinician can save time be taking the new bag on the first 
visit, rather than realizing a new bag is needed after arriving in the patient room. Similarly, the 
pharmacy can view the status, including time remaining, in order to schedule the mixing and 
delivery of the next infusion bag. 

25 If desired, and as will be appreciated by those having skill in the art, other alarms and 

alerts related to the infusion pump can be made available on the electronic computing devices 
remotely located from the infusion pump. Pertinent information can be displayed on the 
electronic computing devices, thus saving the nurse time and steps in resolving the problem. As 
indicated above, when a pump alarms or alerts, the clinician can view patient information, drug 

30 order, and alarm or alert message on the personal digital assistant, and gather necessary items 

before going to the patient room to physically correct the alarm or alert condition. 

In an embodiment, the infusion system 210 provides configurable time-based alerts for 
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reminding clinicians of scheduled infusion orders. As such, a tapering order to run NS at 
200ml/hr for two hours, then reduce to 50ml/hr, results in the infusion system 210 alerting the 
nurse two hours after starting the infusion to reduce the rate. Further, late alerts are provided for 
informing clinicians when scheduled infusions are past the time tolerance set by the facility. 
5 Moreover, time-based protocols such as alerts for conducting pain assessments, such as after 

starting an epidural morphine infusion, are generated. 

Configurable aspects of the infusion system 210 also include the audible alerts emitted 
by the electronic computing devices, such as personal digital assistants. Preferably, the audible 
alerts can be configurable by the healthcare facility and within specific units of the healthcare 

10 facility to satisfy the unique environments within the healthcare facility. 

As indicated previously, a plurality of visual alerts and messages can be displayed by the 
electronic computing devices, such as personal digital assistants, for indicating the importance 
or urgency of the message. Desirably, color, flashing, and bold text are display-messaging 
options. Additionally, hyperlinks can be provided when messages are generated. Icons on the 

15 displays can also be utilized and emergency messages can be configured to interrupt the 

handheld electronic device, or the like, to immediately alert the clinician. Further, escalation of 
alarms/alerts is provided by the system 210. Alarms/alerts and the escalation thereof are 
detailed infra. 

As also indicated previously, the infusion system 210 allows a clinician to view all 
20 infusions or assigned patients on the electronic computing device, such as a personal digital 

assistant or the like, thus reducing time spent traveling to and from patient rooms. Moreover, 
prescription information is displayed on the electronic computing device for verification of the 
drug amount, diluents, dose, and rate of the infusion. Additionally, real time status of the 
infusion is viewable for displaying milliliters per hour or the like, duration of the infusion, 
2 5 volume infused, time remaining, and volume yet to be infused. As indicated previously, the 

status of the infusion and flow rate history can be viewed from anywhere within the healthcare 
facility via the electronic computing devices. 

As described in detail further herein, the infusion system 210 may calculate ordered 
doses based on patient weight and display the appropriate rate to run the infusion. Messages are 
30 generated if the infusion is set to run outside of the ordered dose. Moreover, pediatric dosing is 

available and configured for pediatric units within the healthcare facility. 

In an embodiment, the status of primary infusions and secondary infusions, such as 
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piggybacks, are displayed by the infusion system 210 on the electronic computing device, such 
as a personal digital assistant. The clinician can check the volume left to infuse in a piggyback 
at any time and a message is displayed when the piggyback is completed and the primary 
infusion has resumed. In addition, messages are sent to the pharmacy to replenish stocks and 
infusion orders. 

If desired, the infusion system 210 allows for the healthcare facility to define system 
infusion limits for warning a clinician who programs an infusion to run outside of the set range. 
The warning can be configured to allow clinicians to override the warning or prohibit overrides. 
As will be appreciated by those having ordinary skill in the art, prohibiting overrides for certain 
infusions may prevent a patient from inadvertently receiving an overdose. 

The infusion system 210 can also provide for displaying reference information pertinent 
to the needs of each specialty unit within the healthcare facility. Drug information is viewable 
on the electronic device, such as a personal digital assistant, in addition to specialty unit policies 
and procedures. Protocols and standard orders can be configured to provide messages based on 
patient condition. In an embodiment, for example, heparin infusion protocols are configured to 
alert the clinician of a new blood glucose result and to titrate the insulin infusion by a 
determined number of milliliters based on the sliding scale protocol. 

Moreover, through configured rules, messages or notifications are sent to the nurse 
regarding particular infusions as they relate to the patient's condition. In an embodiment, for 
example, a message is generated when a patient receiving a nephrotoxic infusion has an increase 
in BUN and Creatinine. Additionally, protocols can be configured to generate messages when 
certain infusions are titrated. In an embodiment, for example, a message to document a blood 
pressure can be configured when a clinician titrates a dopamine infusion. Furthermore, 
hemodynamic monitoring parameters can be linked to infusions to generate messages. 

As indicated previously, new infusion orders can be configured to provide messages 
alerting the clinician of a new order. Messages can be configured as audible and visual such as 
textual, color alerts, flashing hyperlinks, icons, and the like. Stat orders and discontinue orders 
can be configured as a high priority message to differentiate them from non-urgent messages. 

Preferably, educational messages are generated and configured by the healthcare facility. 
In an embodiment, for example, an infusion requiring a specific tubing set (e.g., non-PVC) 
results in the display of a message informing the clinician. In a further embodiment, for 
example, an infusion requiring central venous access results in the display of a warning not to 
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infuse in the peripheral vein. 

In an embodiment, scheduling messages are generated and displayed on one or more 
electronic computing devices to remind users to complete the next task. Alerts to change 
infusion rates at scheduled times are sent to the electronic computing devices, such as in the case 
of a tapering infusion. Additionally, protocols with time-based alerts can be configured such as, 
for example, blood infusion protocols. 

Turning again to FIGURE 1, and as indicated above, patient care system 100 allows 
medication ordering, dispensing, and administration to take place at the patient's bedside. 
Physicians can order simple and complex prescriptions, intravenous therapy and total parenteral 
nutrition therapy (TPN) using a wireless handheld device. Infusion system 210 checks for drug 
interactions and other possible errors as well as correct dosage. Infusion system 210 then 
transmits this data in real-time to the patient care facility or local pharmacy, hospital nursing 
unit, home care unit, and/or clinic. 

The clinician can access a medical records database using the handheld device. In an 
embodiment, the clinician scans the bar-coded medication and the patient's bar-coded bracelet to 
confirm the presence of the right medication, dosage, and time before administering any drugs. 
The infusion system 210 updates medical and administrative records, thereby eliminating most, 
if not all, time-consuming paperwork. Thus, infusion system 210 can reduce costs and improve 
efficiency while possibly saving lives. Patient care system 100 can include access-controlled 
mobile and stationary medication and supply depots, including electronic patient medical 
^ records and computerized prescribing, providing complete preparation and inventory 
management from the point of care to the pharmacy. 

As mentioned previously, FIGURE 1 is a graphical representation of patient care system 
100. The patient care system 100 includes a pharmacy computer 104, a central system 108, and 
a treatment location 106, linked by a network 102. In an embodiment, the pharmacy computer 
104 includes a processing unit 104a, a keyboard 104b, a video display 104c, a printer 104d, a bar 
code reader 104e, and a mouse 104f. Although not shown in FIGURE 1, the patient care system 
100 can also include subsystems for hospital administration, nursing stations, a clinical 
information subsystem, a hospital information subsystem, an Admissions Discharge and 
Transfer (ADT) subsystem, a billing subsystem, and/or other subsystems typically included in 
conventional patient care systems. Such systems are typically interfaced with the second central 
server 108a. 
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In an embodiment, the central system 108 includes a central servicing computer 108a, a 
database 108b, a video display 108c, input/output components, and other conventional hardware 
components known to those having ordinary skill in the art. The network 102 preferably 
includes a cable communication system 110 portion and a wireless communication system 
5 portion. The cable communication system 110 can be, but is not limited to, an Ethernet cabling 

system, and a thin net system. 

In an embodiment, the treatment location 106 can include a treatment bed 106a, an 
infusion pump 120, and medical treatment cart 132. In FIGURE 1, a clinician 1 16 and a patient 
112 are shown in the treatment location 106. Medication 124 can be of a type that is 

10 administered using an infusion pump 120 or other medical device. Medication 124 can also be 

of a type that is administered without using a medical device. The medication can be stored in 
medication storage areas 132a of medical treatment cart 132. The clinician 116 uses a digital 
assistant 118 in the process of administering medication 124 to the patient 112. 

In an embodiment, the clinician 116 uses the digital assistant 118 in the course of 

15 treating a patient 112 to communicate with the cable communication system 1 10 of the network 

102 via a first wireless communication path 126. The infusion pump 120 has the ability to 
communicate with the cable communication system 110 via a second wireless communication 
path 128. The medication cart 132 also has the ability to communicate via a wireless 
communication path (not shown in FIGURE 1). A wireless transceiver 114 interfaces with the 

20 cable communication system 110. The wireless communication system portion of the network 

can employ technology such as, but not limited to, known to those having ordinary skill in the 
art such as IEEE 802.11b "Wireless Ethernet," a local area network, wireless local area 
networks, a network having a tree topography, a network having a ring topography, wireless 
internet point of presence systems, an Ethernet, the Internet, radio communications, infrared, 

2 5 fiber optic, and telephone. Though shown in FIGURE 1 as a wireless communication system, 

the communication paths can alternatively be hardwired communication paths. 

In the patient care system 100, a physician can order medication 124 for patient 112. In 
an embodiment, the order can originate with a clinician 116 at the treatment location 106. The 
physician and/or clinician 116 can use a computerized physician order entry system (CPOE), the 

30 medical cart 132, or a like device, to order the medication 124 for the patient 112. Those having 

ordinary skill in the art are familiar with conventional computerized physician order entry 
systems. Despite its name, any clinician 116 can use the computerized physician order entry 
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system. If the medication 124 is efficient to administer through infusion pump 120, the infusion 
order includes information for generating operating parameters for the infusion pump 120. The 
operating parameters are the information and/or instruction set necessary to program infusion 
pump 120 to operate in accordance with the infusion order. 
5 The infusion order can be entered in a variety of locations including the pharmacy, the 

nursing center, the nursing floor, and treatment location 106. When the order is entered in the 
pharmacy, it can be entered in the pharmacy computer 104 via input/output devices such as the 
keyboard 104b, the mouse 104f, a touch screen display, the CPOE system and/or the medical 
treatment cart 132. The processing unit 104a is able to transform a manually entered order into 

10 computer-readable data. Devices such as the CPOE can transform an order into computer- 

readable data prior to introduction to the processing unit 104a. The operating parameters are 
then printed in a bar code format by the printer 104d on a medication label 124a. The 
medication label 124a is then affixed to a medication 124 container. Next, the medication 124 
container is transported to the treatment location 106. The medication 124 can then be 

15 administered to the patient 112 in a variety of ways known in the art including orally and 

through an infusion pump 120. If the medication 124 is administered orally, the clinician 116 
can communicate via the digital assistant 118 and/or the medical cart 132. The medical cart 132 
is computerized and generally has a keyboard (not shown), a display 132b, and other 
input/output devices such as a bar code scanner (not shown). 

20 As will be appreciated by those having ordinary skill in the art, the infusion bag can also 

be premixed, wherein a non-patient specific bar code is attached to the bag identifying the 
medication 124. Moreover, the infusion bag can be mixed in the pharmacy or on the floor, 
wherein a patient specific bar code is attached to the bag that identifies the medication 124 and, 
if desired, when the medication is to be administered to the patient. 

2 5 At the treatment location, the medication 124 can be mounted on the infusion pump 120 

with an intravenous (IV) line 130 running from the infusion pump 120 to the patient 112. The 
infusion pump 120 can include a pumping unit 120a, a keypad 120b, a display 120c, an infusion 
pump ID 120d, and an antenna 120e. Prior art infusion pumps can be provided with a wireless 
adaptor (not shown) in order to fully implement the system 100. The wireless adaptor can have 

30 its own battery if necessary to avoid reducing the battery life of prior art infusion pumps. The 

wireless adaptor can also use intelligent data management such as, but not limited to, store-and- 
forward data management and data compression to minimize power consumption and network 
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traffic. The wireless adaptor can also include the ability to communicate with the digital 
assistant 118 even when the network 102 is not functioning. 

In an embodiment, the patient care system 100 can include a variety of identifiers such 
as, but not limited to, personnel, equipment, and medication identifiers. In FIGURE 1, the 
5 clinician 116 can have a clinician badge 116a identifier, the patient 112 can have a wristband 

112a identifier, the infusion pump 120 can have an infusion pump ID 120d identifier, and the 
medication 124 can have a medication label 124a identifier. Clinician badge 116a, wristband 
112a, infusion pump ED 120d, and medication label 124a include information to identify the 
personnel, equipment, or medication they are associated with. The identifiers can also have 

10 additional information. For example, the medication label 124a can include information 

regarding the intended recipient of the medication 124, operating parameters for infusion pump 
120, and information regarding the lot number and expiration of medication 124. The 
information included in the identifiers can be printed, but is preferably in a device readable 
format such as, but not limited to, an optical-readable device format such as a bar code, a radio 

15 frequency (RF) device-readable format such as an RFID, an iButton, a smart card, and a laser- 

readable format. The digital assistant 118 can include a display 1 18a and have the ability to read 
the identifiers, including biometric information such as a fingerprint. 

The wristband 112a is typically placed on the patient 112 as the patient 112 enters a 
medical care facility. The wristband 112a includes a patient identifier. The patient identifier 

2 0 can include printed information to identify the patient and additional information such as a 

treating physician's name(s). The patient identifier for patient 1 12 can include information such 
as, but not limited to, the patient's name, age, social security number, the patient's blood type, 
address, allergies, a hospital ED number, and the name of a patient's relative. In an embodiment, 
the patient identifier can contain a unique reference code or password for the patient, which is 

2 5 also stored in the central database for cross referencing, if needed or desired. 

System Hardware/Software Architecture of the System 

FIGURE 2 is a block diagram of a computer 200 representative of the pharmacy 
computer 104, the central system 108, the CPOE, the digital assistant 118 of FIGURE 1, and/or 
a computer included in any number of other subsystems that communicate via the network 102 

3 0 such as the medication treatment cart 132. As indicated previously, the computer 200 includes 

an infusion system 210, or a portion of infusion system 210, for use within the patient care 
system 100. The infusion system as described in reference to FIGURE 2 is preferably a 
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computer program. However, the infusion system can be practiced in whole or in part as a 
method and system other than as a computer program. 

A critical concern in the art is that the right medication is administered to the right 
patient. Therefore, infusion system 210 includes features to assist in assuring that the right 
5 medication is administered to the right patient in an efficient manner. Infusion system 210 can 

be implemented in software, firmware, hardware, or a combination thereof. In one mode, 
infusion system 210 is implemented in software, as an executable program, and is executed by 
one or more special or general purpose digital computer(s), such as a personal computer (PC; 
IBM-compatible, Apple-compatible, or otherwise), personal digital assistant, workstation, 

10 minicomputer, or mainframe computer. An example of a general -purpose computer that can 

implement the infusion system 210 is shown in FIGURE 2. The infusion system 210 can reside 
in, or have various portions residing in, any computer such as, but not limited to, pharmacy 
computer 104, central system 108, medication treatment cart 132, and digital assistant 118. 
Therefore, the computer 200 of FIGURE 2 is representative of any computer in which the 

15 infusion system 210 resides or partially resides. 

Generally, in terms of hardware architecture, as shown in FIGURE 2, the computer 200 
includes a processor 202, memory 204, and one or more input and/or output (I/O) devices 206 
(or peripherals) that are communicatively coupled via a local interface 208. The local interface 
208 can be, for example, but not limited to, one or more buses or other wired or wireless 

20 connections, as is known in the art. The local interface 208 can have additional elements, which 

are omitted for simplicity, such as controllers, buffers (caches), drivers, repeaters, and receivers, 
to enable communications. Further, the local interface can include address, control, and/or data 
connections to enable appropriate communications among the other computer components. 

Processor 202 is a hardware device for executing software, particularly software stored 

2 5 in memory 204. Processor 202 can be any custom made or commercially available processor, a 

central processing unit (CPU), an auxiliary processor among several processors associated with 
the computer 200, a semiconductor-based microprocessor (in the form of a microchip or chip 
set), a macroprocessor, or generally any device for executing software instructions. Examples of 
suitable commercially available microprocessors are as follows: a PA-RISC series 

30 microprocessor from Hewlett-Packard Company, an 80x86 or Pentium series microprocessor 

from Intel Corporation, a PowerPC microprocessor from IBM, a Sparc microprocessor from Sun 
Microsystems, Inc., or a 68xxx series microprocessor from Motorola Corporation. Processor 
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202 can also represent a distributed processing architecture such as, but not limited to, SQL, 
Smalltalk, APL, KLisp, Snobol, Developer 200, MUMPS/Magic. 

Memory 204 can include any one or a combination of volatile memory elements (e.g., 
random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)) and nonvolatile 
5 memory elements {e.g., ROM, hard drive, tape, CDROM, etc.). Moreover, memory 204 can 

incorporate electronic, magnetic, optical, and/or other types of storage media. Memory 204 can 
have a distributed architecture where various components are situated remote from one another, 
but are still accessed by processor 202. 

The software in memory 204 can include one or more separate programs. The separate 

10 programs comprise ordered listings of executable instructions for implementing logical 

functions. In FIGURE 2, the software in memory 204 includes the infusion system 210 in 
accordance with the present embodiment and a suitable operating system (O/S) 212. A non- 
exhaustive list of examples of suitable commercially available operating systems 212 is as 
follows: (a) a Windows operating system available from Microsoft Corporation; (b) a Netware 

15 operating system available from Novell, Inc.; (c) a Macintosh operating system available from 

Apple Computer, Inc.; (d) a UNIX operating system, which is available for purchase from many 
vendors, such as the Hewlett-Packard Company, Sun Microsystems, Inc., and AT&T 
Corporation; (e) a LINUX operating system, which is freeware that is readily available on the 
Internet; (f) a real time VxWorks operating system from WindRiver Systems, Inc.; or (g) an 

20 appliance-based operating system, such as that implemented in handheld computers or personal 

digital assistants (PDAs) (e.g., PalmOS available from Palm Computing, Inc., and Windows CE 
available from Microsoft Corporation). Operating system 212 essentially controls the execution 
of other computer programs, such as infusion system 210, and provides scheduling, input-output 
control, file and data management, memory management, and communication control and 

2 5 related services . 

Infusion system 210 can be a source program, executable program (object code), script, 
or any other entity comprising a set of instructions to be performed. When a source program, 
the program is translated via a compiler, assembler, interpreter, or the like, that may or may not 
be included within the memory 204, so as to operate properly in connection with the O/S 212. 

30 Furthermore, the infusion system 210 can be written as (a) an object-oriented programming 

language, which has classes of data and methods, or (b) a procedural programming language, 
which has routines, subroutines, and/or functions, for example, but not limited to, C, C++, 
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Pascal, Basic, Fortran, Cobol, Perl, Java, and Ada. In one embodiment, the system program 210 
is written in C++. In other embodiments, the infusion system 210 is created using Power 
Builder. The I/O devices 206 can include input devices, for example, but not limited to, a 
keyboard, mouse, scanner, microphone, touch screens, interfaces for various medical devices, 
5 bar code readers, stylus, laser readers, radio-frequency device readers, etc. Furthermore, the I/O 

devices 206 can also include output devices, for example, but not limited to, a printer, bar code 
printers, displays, etc. The I/O devices 206 can further include devices that communicate as 
both inputs and outputs, for instance, but not limited to, a modulator/demodulator (modem; for 
accessing another device, system, or network), a radio frequency (RF) or other transceiver, a 

10 telephonic interface, a bridge, a router, etc. 

If the computer 200 is a PC, workstation, personal digital assistant, or the like, the 
software in the memory 204 can further include a basic input output system (BIOS) (not shown 
in FIGURE 2). The BIOS is a set of essential software routines that initialize and test hardware 
at startup, start the O/S 212, and support the transfer of data among the hardware devices. The 

15 BIOS is stored in ROM so that the BIOS can be executed when the computer 200 is activated. 

When the computer 200 is in operation, processor 202 is configured to execute software 
stored within memory 204, to communicate data to and from memory 204, and to generally 
control operations of the computer 200 pursuant to the software. The infusion system 210 and 
the O/S 212, in whole or in part, but typically the latter, are read by processor 202, perhaps 

2 0 buffered within the processor 202, and then executed. 

When the infusion system 210 is implemented in software, as is shown in FIGURE 2, 
the infusion system 210 program can be stored on any computer-readable medium for use by or 
in connection with any computer-related system or method. As used herein, a computer-readable 
medium is an electronic, magnetic, optical, or other physical device or means that can contain or 

2 5 store a computer program for use by or in connection with a computer related system or method. 

The infusion system 210 can be embodied in any computer-readable medium for use by or in 
connection with an instruction execution system, apparatus, or device, such as a computer-based 
system, processor-containing system, or other system that can fetch the instructions from the 
instruction execution system, apparatus, or device and execute the instructions. In the context of 

30 this document, a "computer-readable medium" can be any means that can store, communicate, 

propagate, or transport the program for use by or in connection with the instruction execution 
system, apparatus, or device. The computer-readable medium can be, for example, but not 
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limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, 
apparatus, device, or propagation medium. More specific examples (a non-exhaustive list) of 
the computer-readable medium would include the following: an electrical connection 
(electronic) having one or more wires, a portable computer diskette (magnetic), a random access 
5 memory (RAM) (electronic), a read-only memory (ROM) (electronic), an erasable 

programmable read-only memory (EPROM, EEPROM, or Flash memory) (electronic), an 
optical fiber (optical), and a portable compact disc read-only memory (CDROM) (optical). Note 
that the computer-readable medium could even be paper or another suitable medium upon which 
the program is printed, as the program can be electronically captured via, for instance, optical 

10 scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a 

suitable manner if necessary, and then stored in a computer memory. 

In another embodiment, where the infusion system 210 is implemented in hardware, the 
infusion system 210 can be implemented with any, or a combination of, the following 
technologies, that are each well known in the art: a discrete logic circuit(s) having logic gates for 

15 implementing logic functions upon data signals, an application specific integrated circuit (ASIC) 

having appropriate combinational logic gates, a programmable gate array(s) (PGA), a field 
programmable gate array (FPGA), etc. 

Any process descriptions or blocks in figures, such as FIGURES 3-11, are to be 
understood as representing modules, segments, or portions of hardware, software, or the like, 

20 that can include one or more executable instructions for implementing specific logical functions 

or steps in the process, and alternate implementations are included within the scope of the 
embodiments in which functions can be executed out of order from that shown or discussed, 
including substantially concurrently or in reverse order, depending on the functionality involved, 
as would be understood by those having ordinary skill in the art. 

2 5 Patient Care System Components 

FIGURE 4 is a first block diagram showing functional components of the patient care 
system 100 of FIGURE 1. As shown in FIGURE 4, the patient care system 100 can be practiced 
as a modular system where the modules represent various functions of the patient care system, 
including the infusion system 210 (FIGURE 2). The flexibility of the patient care system 100 

30 and the infusion system can be enhanced when the systems are practiced as modular systems. 

The modules of the infusion system 210 (FIGURE 2) can be included in various portions of the 
patient care system 100. In an embodiment, the patient care system functional components can 
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include, inter alia, a medication management module 302, a prescription generation module 304, 
a prescription activation module 306, and a prescription authorization module 308. 

The medication management module 302 can coordinate the functions of the other 
modules in the patient care system 100 that are involved in the administration of medical 
5 treatment. The medication management module 302 generally coordinates with other portions 

of the patient care system 100. The medication management module 302 can include sub- 
modules for operating and/or interfacing with a CPOE, for operating and/or communicating with 
point-of-care modules, and for operating and/or communicating with medical treatment 
comparison modules. In FIGURE 4, an admissions, discharge, and transfer (ADT) interface 

10 310, a billing interface 312, a lab interface 314, and a pharmacy interface 316 are shown. The 

ADT interface 310 is used to capture information such as the patient's demographics, size, 
weight, and allergies. In a preferred embodiment, the ADT system utilizes an HL7 type of 
interface to transfer events that are entered into the hospital's ADT system into the second 
central server 108a. HL7 is a protocol for formatting, transmitting and receiving data in a 

15 healthcare environment. It provides interoperability between healthcare information systems 

through a messaging standard that enables disparate healthcare applications, such as a variety of 
different third-party applications, to exchange key sets of clinical and administrative data. 
Typically, in the present system 100, the HL7 ADT interface consists of three applications: the 
HL7 ADT server, the HL7 ADT client, and the HL7 ADT viewer. The pharmacy interface 316 

2 0 imports orders from the pharmacy. The pharmacy interface 316 can be an HL7-type of interface 

that interfaces with other systems for entering orders, such as a CPOE. This ability reduces the 
necessity for entering data into the patient care system 100 more than once. The pharmacy 
interface 316 can be configured to communicate with commercially available third-party 
systems such as, but not limited to Cerner, HBOC, Pyxis, Meditech, SMS, Phamous, and the 

2 5 like. A web services interface can provide near real-time coordination between Point of Care 

medication management systems supporting oral medication dosing such as McKesson 
AdminRx, Pyxis Verif5, etc. and infusion pump related medication management. Various other 
interfaces are also known to those having ordinary skill in the art, but are not shown in FIGURE 
4. 

30 The medication management module 302 can have additional features such as the ability 

to check for adverse reactions due to drug-to-drug incompatibility, duplicate drug 
administration, drug allergies, drug dosage limitations, drug frequency limitations, drug duration 
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limitations, and drug disease contraindications. Food and alcohol interactions can also be noted. 
Drug limitations can include limitations such as, but not limited to, limitations associated with 
adults, children, infants, newborns, premature births, geriatric adults, age groupings, weight 
groupings, height groupings, and body surface area. In an embodiment, the medication 
management module 302 prevents the entry of the same prescription for the same patient from 
two different sources within the patient care system 100. 

The medication management module 302 can also include the ability to generate reports. 
The reports include, but are not limited to, end-of-shift, titration information, patient event lists, 
infusion history, pump performance history, pump location history, and pump maintenance 
history. The end-of shift report can include the pump channel, start time, end time, primary 
infusion, piggyback infusion, medication, dose, rate, pump status, volume infused, volume 
remaining, time remaining, and the last time cleared. The infusion history report includes 
medications and volume infused. 

The medication management module 302 can also include a medical equipment status 
database. The medical equipment status database includes data indicating the location of a 
medical device 332 within the patient care system 100. The medical equipment status database 
can also include data indicating the past performance of a medical device 332. The medical 
equipment status database can also include data indicating the maintenance schedule and/or 
history of a medical device 332. 

Infusion prescriptions or orders are entered in prescription entry 324. Such orders can 
include prescriptions such as, but not limited to, single dose infusions, intermittent infusions, 
continuous infusions, sequencing, titrating, and alternating types. Infusion prescriptions can also 
include total parenteral nutritional admixtures (TPN), chemotherapy continuous infusion, 
piggybacks, large volume parenterals, and other infusion prescriptions. The patient care system 
100 can function without end dates for orders. The patient care system 100 uses a continuous 
schedule generator that looks ahead a predefined time period and generates a schedule for 
admixture filling for the time period. The predefined time period can be defined at the patient 
care system 100 level or at subsystem levels such as the clinical discipline level and an 
organizational level. The predefined time periods can be adjustable by the clinician 116 entering 
the order. The schedule can be automatically extendable as long as the order is active in the 
patient care system 100. 

The prescription generation module 304 generates hard prescriptions and electronic (E- 
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copy) prescriptions. Hard prescriptions are generally produced in triplicate in medical facilities. 
A first hard copy 318 is generally sent to the pharmacy, a second hard copy 320 is generally kept 
for the patient's records, and a third hard copy 322 is sent to treatment location 106. An 
electronic prescription is sent to the medication management module 302. 

Prescription generation module 304 can include confirming operating parameters. The 
operating parameters can be based on information from prescription entry module 324. 
Prescription generation 304 can occur anywhere in the patient care system 100 such as, but not 
limited to, the pharmacy, the treatment location 106, and a nursing center. 

A computerized physician order entry (CPOE) system or the like can be employed to 
carry out some or all of the functions of the prescription generation module 304. Clinicians 116 
can enter data in a variety of manners such as, but not limited to, using a tablet wireless 
computer, personal digital assistant, treatment cart 132, and a workstation. The medication 
management module 302 can interface with more than one prescription generation module 304. 
The medication management module can receive orders from anywhere within the patient care 
system 100. 

The pharmacy computer 104 is able to access the electronic copy from the medication 
management module 302. The prescription activation module 306 is a computer-assisted system 
for coordinating the filling and labeling of prescriptions. The filling of the prescription and the 
creation or location of medication 124 from stock is handled by the prescription activation 
module 306. In an embodiment, the filling process results in the creation of the medication label 
124a, as opposed to the prescription activation process. 

The patient care system 100 can bypass the prescription activation module 306. This can 
occur if the ordering clinician 116, such as the patient's physician, has the authority to 
immediately activate an order. If the order is immediately activated, the medication 
management module 302 can go directly to filling and, thus, the prescription labeling module 
326. 

In block 326, the patient care system 100 prints the medication label 124a. The 
prescription can be printed remotely and will often be printed by the pharmacy printer 104d. 
After block 326, the patient care system goes to block 328. In block 328, the medication label 
124a is attached to the medication 124. The pharmacist generally provides a visual verification 
334 that the medication label 124a matches the first hard copy 318 of the prescription. FIGURE 
4 shows that a visual verification 334 is also associated with prescription authorization module 
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308. The medication 124 can then be transported from the pharmacy to the treatment location 
106. A portable medical treatment cart 132 can be used for a portion of the route from the 
pharmacy to the treatment location 106. 

The medication label 124a can include information for preparing the infusion bag. If not 
5 generated within patient care system 100, medication label 124a can be provided by a bulk 

medication supplier. If provided by a bulk medication supplier, the patient care system 100 
gathers the information from the medication label 124a. In addition, the patient care system 100 
can add information, such as a patient identifier, to the medication label 124a. 

The medication labeling module 328 places the medication label 124a on the medication 

10 124. This can be accomplished manually. This can also be accomplished using an automatic 

prescription filling and packaging system (not shown). If an automatic filling and packaging 
system is used, medication labeling module 328 provides data for coordination of the labeling of 
the medication 124 to the filling and packaging system. 

At the treatment location 106, the clinician 116 uses a wireless device 330, such as 

15 digital assistant 118 and/or medical treatment cart 132, to verify and administer medication 124 

to the patient 112. Wireless device 330 communicates with the medication management module 
302 via a communication path, such as first communication path 126. 

Clinician 116 identifies him/herself by scanning badge 116a, identifies the patient 112 
by scanning wristband 112a, identifies the medication 124 by scanning medication label 124a, 

20 and identifies the medical device 332, such as infusion pump 120, by scanning label 120d. 

Clinician 116 can also identify him/herself by providing a fingerprint and/or password as 
described above and shown in the login screen 1903 of FIGURE 19. The medical device 332 
can be a medical device capable of two-way communication with the medication management 
module 302. Alternatively, the medical device 332 can only be capable of providing 

2 5 information to the medication management module 302. The infusion system 210 assists the 

clinician 1 16 in administering and verifying the medical treatment. In an alternate embodiment, 
the infusion system 210 can include downloading of operating parameters to the medical device 
332. Clinician 116 can provide a visual verification to confirm the third copy 322 and/or the 
MAR matches the labeled medication 124. Scanner 338 can be used to enter machine readable 

30 information from the third copy 322 to the wireless device 330 and the medical device 332. 

The patient care system 100 can make adjustments and modifications to infusion orders. 
Among other modules that can include the ability to make infusion adjustments are prescription 
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entry 324, prescription activation 306, prescription authorization 308, and prescription 
modification module 336. Clinician 116 accesses the prescription modification module 336 in 
order to make adjustments to an order. The clinician 116 can access the prescription 
modification module 336 throughout the patient care system 100. However, one very useful 
5 location for clinician 116 to access the prescription modification module 336 is at treatment 

location 106. 

In prescription authorization module 308, the patient care system 100 determines 
whether the clinician 116 has the authority to independently modify an infusion order. The 
clinician 116 can be recognized by the patient care system 100 as having the authority to 

10 independently modify certain portions of the order. If the clinician 116 does not have the 

authority to independently modify the order, a pharmacist or physician can be requested to 
approve the modification entered by the clinician 116. 

In one implementation of patient care system 100, an order is entered in pharmacy 
computer 104. The order includes a first patient identifier and an operating parameter. The 

15 pharmacy computer 104 generates a medication label 124a that is affixed to the medication bag 

or container. The medication 124 is sent to a treatment location 106. At treatment location 106, 
clinician 116 reads the clinician's badge 116a, patient's wristband 112a, and medication label 
124a with a digital assistant 118. The digital assistant 118 reports, based on a determination 
made by the central system 108, whether medication label 124a and wristband 1 12a correspond 

20 to the same patient 112. The system 100 then sends the medication identifier to the pharmacy 

computer 104. The pharmacy computer 104 confirms the medication label 124a, identifies the 
same patient as the order, and sends the operating parameter to an infusion pump. The operating 
parameter can be sent directly to the infusion pump 120. The operating parameter is then used 
to program the infusion pump to administer the medication 124 to the patient 112. 

2 5 FIGURE 5 is an exemplar block diagram of a computer screen 400 that is useful in 

implementing various functions of the infusion system 210 (FIGURE 2). In addition to other 
functions, the computer screen 400 can be used to enter new infusion orders, to modify existing 
infusion orders, and to stop infusion orders. Computer screen 400 preferably includes a 
processing area 402, search areas 404, a medication information area 406, a titration/tapering 

30 criteria area 408, an instruction and note area 410, and a projected solution ingredient area 412. 

Infusion medication order types include single dose, intermittent, continuous, sequencing, and 
alternating. Computer screen 400 can be used with digital assistant 118, pharmacy computer 
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104, infusion pump 120, a CPOE system, and medical treatment cart 132. Computer screen 400 
is generally designed to have the look-and-feel of clinician accessible computer screens 
throughout the patient care system 100 of FIGURE 1. The functions of computer screen 400 are 
partially accomplished with database linkage techniques familiar to those having ordinary skill 
5 in the art such as, but not limited to, hyperlinks, definition boxes, and dropdown menus. 

The processing area 402 includes the ability to trigger the creation of an infusion order, a 
save of an infusion order, the modification of an infusion order, and a cancellation of an infusion 
order. Clinician 116 can customize the computer screen 400 to provide the clinician's 116 
preferred order entry procedures. The processing area 402 includes a status indicator for orders. 

10 The processing area 402 also includes an area for indicating whether a PRN order ("as required" 

or "when needed" order) can be placed by clinician 116. The processing area 402 further 
includes the ability to display and adjust medical device 332 operating parameters, infusion 
order route, infusion line, infusion administration site, infusion order start time, infusion 
medication order type, infusion flow rate tolerance, infusion flow rate, infusion duration and 

15 area of preparation (such as pharmacy or a remote site). The processing area 402 can also 

include an area for linking medical orders to other medical orders, or associated clinical 
monitoring, such as, linking a physician's infusion order to another medical order entered by 
another clinician 116. The processing area 402 can include a trigger for displaying data in other 
areas of the computer screen 400 such as, but not limited to, the projected solutions area 412. 

2 0 Search areas 404 allow for searching for medications, solutions and/or additives for 

infusion orders. Default diluents can be provided for orders. If a default dosage for a 
medication is defined in the patient care system 100, the default dosage automatically appears 
with the search result that includes the medication. A search from search area 404 can result in 
the display of the medication name, the route of administration, the cost, the package size, the 

2 5 dosage form, the generic name, whether the medication is a narcotic, whether the medication is 

controlled, whether formulary, and whether the medication is manufactured. 

Medication information area 406 can be used to define infusion order additives and 
solutions. Medication information area 406 can include separate additive areas and solution 
areas. The solution area can include a label, "Solution/Diluents." The patient care system 100 

30 may use a medication 124 database, a solutions database, and an additive database to populate 

the medication information area 406 with medications 124, solutions, and additives. Substances 
identified in one database may also be identified in other databases. The databases may be 
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linked to provide default values for combinations of the medications 124 and solutions. 

Titration/tapering criteria area 408 generally applies to continuous infusion orders. 
Titration defines certain parameters of an order such as dosage and/or flow rate. Dose and flow 
rate can be entered as an absolute. Also, mathematical symbols such as, but not limited to, 
5 greater than ">," less than "<," and equal "=," can be used alone or in combination to enter 

information in titration/tapering criteria area 408. A calendar can also be used to enter data in 
titration/tapering criteria area 408. Dosage and flow rate can also be entered as an acceptable 
range. Titration/tapering criteria area 408 can be hidden when non-continuous infusion orders 
are entered and/or modified. The titration criteria can include values of various parameters 

10 related to patient condition such as, but not limited to, various lab results, vital signs, ability to 

take fluids orally, fluid input and output, and the like. 

Instruction and note area 410 includes the ability to save information such as physician 
notes regarding a patient 112 and/or an infusion order. The instruction and note area 410 can 
include a display and lookup area for identifying clinicians 116 that are responsible for the 

15 patient 112, such as the patient's physician. 

The projected solutions area 412 displays solution schedules and related ingredients 
based on the current state of the order being processed for patient 112. The time period 
projected can be a patient care system 100 default. The time period can also be adjustable by the 
clinician 116. The projected solutions area 412 can include an adjustable display indicating the 

20 time period projected by the patient care system 100. The data displayed in the projected 

solutions area 412 is generally saved when an order save is triggered in the processing area 402. 
The projected solutions area 412 can include the ability to look back over a period of time while 
modifying a previously entered order. This allows the clinician 116 to view solutions that may 
have already been prepared according to the unmodified infusion order. 

2 5 Infusion System Components 

FIGURE 6 is a block diagram showing functional components of the infusion system 
210 of FIGURE 2. The functional components include blocks for setting system parameters 
502, infusion order creation 504, infusion order preparation 506, medication administration 512, 
infusion order modifications 514, and messaging 520. FIGURE 6 also includes blocks for 

30 pharmacy authorization 508, physician authorization 510, stop orders 516, and inventory and 

billing 518. FIGURE 6 presents one description of the infusion system. However, FIGURE 6 
does not define a required series of processes for implementing the infusion system. One of the 
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benefits of the infusion system is that a clinician 116 can access and enter information from a 
large number of locations, both physical and functional, within the patient care system 100. For 
example, an infusion order can be created by a physician using a CPOE, by a pharmacist using 
pharmacy computer 106, by a clinician 116 using digital assistant 118, and by a clinician using 
medication treatment cart 132. Moreover, vitals, lab results, and other records of patients can be 
checked from a large number of locations within the health care facility including, for instance, 
the inpatient pharmacy. Accordingly, a user within the inpatient pharmacy 104 (FIGURE 1) can 
view, from a computing device 104c, the wards within the health care facility. Upon selection 
of a ward by the user, a patient list is provided wherein the user can select a patient and 
associated records for display on the computing device. Alternatively, the user can enter all or 
part of the patient's name into the computing device, whereby the records associated with the 
patient are provided by the computing device for selection by the user. Upon selection, the 
record(s) is displayed. 

In an embodiment, FIGURE 6 can be viewed as first preparing the patient care system 
100 for receiving infusion orders - setting system parameters 502; second, creating the infusion 
order - infusion order creation 504; third, preparing the infusion order - preparation 506; fourth, 
authorizing the infusion order - pharmacy and physician authorization 508 and 510; fifth, 
administering the infusion order - medication administration 512; sixth, accounting for and 
replenishing the inventory used to prepare the infusion order and billing the patient for the 
infusion order - inventory and billing 518; seventh, modifying the infusion order - 
modifications 514; and eighth, providing messages to various personnel and sub-systems 
regarding the progress of the infusion order, infusion, messages for assisting in ensuring that the 
right medication is efficiently prepared and provided to the right patient, in the right dose and at 
the right time, or the like - messages 520. Modifications 514 can include stopping the order - 
stop order 516 - based on information provided by the transfer interface 310. 

Setting system parameters 502 includes functional blocks that prepare the infusion 
system 210 to create and process infusion orders. Setting system parameters 502 includes, but is 
not limited to, setting tolerances 542, setting defaults 544, building databases 546, defining 
functions 548, and determining system settings 550. Setting system parameters 502 is further 
described below in reference to FIGURE 7. 

Infusion order creation 504 includes functional blocks used to create infusion orders. 
Infusion order creation 504 includes functions similar to those described in reference to 
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prescription generation 304 (FIGURE 4). Infusion order creation 504 includes, but is not 
limited to, entering information 560, calculations 562, checks 564, and overrides 566. Infusion 
order creation is further described below in reference to FIGURE 8. The result of infusion order 
creation is an infusion order 702 (FIGURE 8). Infusion order 702 generally includes an infusion 
5 schedule 704 (FIGURE 8). 

Infusion orders can require authorization as described in reference to block 308 
(FIGURE 4). In FIGURE 6, prescription authorization by the pharmacist and prescription 
authorization by the physician are considered separately in functional blocks for pharmacy 
authorization 508 and physician authorization 510. Physician authorization 510 may not be 

10 required if the infusion order is initiated by the physician. The infusion order generally requires 

pharmacy authorization 508 and physician authorization 510 if the order is generated by a 
clinician at the treatment location 106, other than the pharmacist or physician. However, if 
medication 124 is required immediately, the infusion system 210 allows administering clinicians 
to bypass prescription authorization 508 and physician authorization 510. In the case of 

15 emergency orders or non-emergency orders for routine medications, the infusion system 210 can 

determine there is no information stored in the patient care system 100 related to the medical 
treatment the clinician 116 desires to administer to the patient 112. If the infusion system 100 
recognizes the clinician 116 as having the authority to initiate the desired medical treatment, the 
system 210 allows for the administration of the medical treatment without going to blocks 508 

20 and 510. This authorization is then obtained following administration. 

Infusion order preparation 506 can be accomplished in a number of locations throughout 
the medical facility such as, but not limited to, the pharmacy, the nursing center, on the floor, 
and the treatment location 106. Preparation 506 includes providing instructions for preparing 
the medication 124 and minimizing the possibility of errors in medication preparation. 

2 5 Medication administration 512 takes place at the treatment location 106. The infusion 

system 210 is designed to make the administration of the order as efficient and accurate as 
possible. The infusion system 210 provides the administrating clinician with the tools to 
administer the right medication to the right patient in the right dose, with the right pump 
settings, at the right time, and via the right route. Should an alert, alarm, reminder, or other 

30 message be appropriate in assisting the clinician with the administration of the medication, the 

medication administration module provides a status information output to the messaging module 
520. In response to the status information output, the messaging module 520 forwards a related 
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text message, audible indicator enable, or both, to one or more electronic computing devices. 

As known by those having skill in the art, infusion orders are frequently modified. 
Infusion system 210 provides modifications 514 to account for infusion order modifications. 
Modification 514 includes modifications to infusion duration, flow rate, infusion site, and stop 
orders 516. Modification 514 also includes the functional blocks required to implement infusion 
order modifications. 

The infusion system 210 can include patient care system wide 100 defined stop orders 
516. Changes in patient status may generate messages 520 for appropriate action. The infusion 
system 210 coordinates with the transfer interface 310 to automatically stop orders 516 upon 
discharge or death. 

The system 100 includes inventory and billing module 518. Inventory and billing 518 
allows the financial transactions associated with patient care to proceed with a minimum of 
human intervention. The completion of medication administration 512 can trigger patient billing 
through the billing interface 312. The billing interface can include an HL7 interface. If patients 
are to be charged based on completion of infusion order preparation 506, the inventory and 
billing system 210 includes a crediting process. The crediting process can be triggered when 
infusion bags are returned to the pharmacy for disposal or re-entry into the pharmacy inventory 
management system. 

The infusion system 210 includes a messages module 520 for communicating with 
entities throughout the patient care system 100. In particular, the messages module 520 sends 
text messages, audible indication enables, or both, to one or more electronic computing devices 
within the patient care system 100. The messages are sent in response to a status information 
output provided by the medication administration module or other infusion system modules 
within the patient care system 100. The messages relate to the status information output and, as 
such, provide alerts, alarms, reminders, or other messages appropriate in assisting the clinician 
with medication administration. 

For example, when a physician enters a new order, messaging appears in the pharmacy 
to alert the pharmacists that an infusion order requires authorization. Likewise, when infusion 
orders are appropriately authorized, the clinician 116 receives messaging on digital assistant 118 
to alert the clinician 116 that the infusion order should be administered according to the infusion 
schedule 704. Overrides 566 may generate messages 520 for the physician and/or the pharmacy. 
The infusion system 100 can distinguish between system- wide and sub-system overrides in 
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determining whether it is necessary to generate a message 520. Messaging 520 includes 
messages received and/or sent to the central system, the pharmacy, the physician, billing, and 
inventory. 

The system can present clinicians 116 with personal computer display views. The 
5 personal computer display provides a view summarizing outstanding clinical problems for the 

clinician's patients. The clinician 1 16 can quickly retrieve detailed information for the patients. 
The system 100 can also produce an email or page to digital assistant 118, or other 
communication device, when certain critical patient conditions prevail. 

FIGURE 6 also depicts some of the communication paths that occur in patient care 

10 system 100. The highlighted communication paths are presented for ease in describing the 

infusion system 210. Those having ordinary skill in the art recognize that, when patient care 
system 100 is practiced on a network, the various functional blocks can communicate with each 
other via the paths highlighted in FIGURE 6 and via alternate paths that are not shown in 
FIGURE 6. Setting system parameters 502 includes communicating data related to the system 

15 parameters to infusion order creation 504, via path 522, and/or receiving data from infusion 

order creation 504 and providing data informing infusion order creation 504 of how the received 
data relates to the system parameters. 

Infusion orders can be passed directly, via path 524, to infusion preparation 506. 
Infusion orders can also be passed to pharmacy authorization 508, via path 526 and/or to 

20 physician authorization, via path 528, before being sent to preparation 506. Path 530 highlights 

the delivery of the medication 124 from the preparation area to the treatment location 106. 
Delivery can be accomplished using medication treatment cart 132. Paths 532, 534, 536, and 
538 highlight that inventory and billing 518 transactions can be tied to a variety of other 
functions such as, but not limited to, infusion order creation 504, preparation 506, medication 

2 5 administration 512, and modifications 514. Paths 572, 574, and 576 highlight that a larger 

number of functions and actors involved in patient care system 100 can generate and receive 
information via messages 520. Path 582 highlights that system defaults 544 can be created 
and/or modified by the pharmacist. And, path 580 highlights that information, such as infusion 
orders, is available to a variety of functional units throughout the system 100. 

3 0 FIGURE 7 is a block diagram showing functional components for the setting of system 

parameters 502 of FIGURE 6. Setting system parameters 502 includes, but is not limited to, 
setting tolerances 542, setting defaults 544, building databases 546, defining functions 548, and 
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determining system settings 550. Tolerances 542 include tolerances such as, but not limited to, 
net medication tolerances 542a, flow rate tolerances 542b, administration time tolerances 542c, 
administration system duration 542d, medication duration tolerances 542e, and site change 
tolerances 542f. The infusion system 210 can also include separate tolerances for order entry 
5 and modifications from the ordered tolerances. For example, separate tolerances can be 

identified such as, but not limited to, an administration system duration 542d, an order entry 
maximum infusion duration override availability setting, and an administration maximum 
infusion duration override availability setting. 

A net medication tolerance 542a is a maximum concentration of a medication that is safe 

10 to administer to a patient during a given period of time. The infusion system 210 associates the 

net medication tolerances with medications. Net medication tolerances 542a can be defined in 
medication identification files in a medication database. During infusion order creation 504, the 
infusion system 210 can determine the flow rate 560e, the number of infusion bags required 
562a for a specified period of time, the concentration of the primary ingredient in each infusion 

15 bag, the time period over which each infusion bag is to be administered, and the total volume of 

each infusion bag. Flow rates can be manually entered or adjusted by altering the final 
concentration or the duration of each infusion bag. In an embodiment, the infusion system 210 
performs a net concentration check 564a (FIGURE 8) to ensure the maximum concentration of 
the medication is not exceeded. However, if at any time while a clinician 1 16 is modifying the 

20 flow rate by adjusting the final concentration resulting in the final concentration of a solution 

exceeding the maximum concentration of the medication, the infusion system 210 sends a 
message 520 to the administering clinician. The administering clinician can be authorized to 
override the net medication tolerance 542a. The infusion system 210 can require the clinician 
1 16 to provide a reason for the override. 

2 5 Infusion system 210 can include adjustable flow rate tolerances 542b and flow rate 

adjustment tolerances for administration. Flow rate tolerances 542b are optionally defined for 
all organizational levels of the patient care system 100. The tolerances 542b can be for the 
entire patient care system 100, or for sub-systems of the patient care system 100. For example, 
different flow rate tolerances 542b can apply to sub-systems such as, but not limited to, 

30 neonatal, pediatric, psychiatric, specific nursing units, and for specific patients. The flow rate 

tolerances 542b can be specified relative to the original ordered flow rate or relative to the 
immediately preceding flow rate. The clinician 116 can also specify a flow rate tolerance 
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specific to a particular order. 

The infusion system 210 can include a pre-defined indication of whether the 
administering clinician 116 is permitted to override the flow rate tolerance 542b without 
requiring a new order. This indication can apply to the entire patient care system 100, a sub- 
5 system, or an individual clinician 116. 

The maximum infusion duration 542d can be separately definable for the various 
portions of the patient care system 100. The maximum infusion duration 542d can also be 
specific to a particular medication 124. A maximum infusion duration override 566 (FIGURE 
8) can be provided if it is permissible to override the maximum infusion duration 542d at the 

10 time of order entry. An administration maximum infusion duration override can be provided to 

set whether it is permissible to override the maximum infusion duration 542d at the time of 
administration and which group of users is allowed to do so. If it is permissible to override 
during order entry and/or administration, the infusion system 210 can define a subset of the 
clinicians 116 that have the authority to override the maximum infusion duration 542d. 

15 Defaults 544 include defaults such as, but not limited to, medication diluents defaults 

544a, diluents quantity defaults 544b, dose defaults 544c, and units of measure defaults 544d. 
Units of measurement (UOM) defaults 544d include the ability to specify the units of 
measurement that are most suitable for different portions of the patient care system 100. For 
example, medication can be measured in different units by physicians, administering clinicians, 

2 0 pharmacists, financial personnel, and medication screeners. The physician's UOM is generally a 

measurable value such as "mmol," "mEq," "ml," and/or "mg," as opposed to "vial" and/or 
"puff." The physician's UOM is used for tasks such as ordering and entering information 560. 

The administering clinician's UOM is generally a value that reflects the UOM the 
medication will be administered in, such as "puff," "tbsp," and "tab." The administering 

2 5 clinician's UOM is used during medication administration 512. The administering clinician's 

UOM can also appear on documentation such as administration reports, admixture fill and 
manufacturing work orders. 

The pharmacy UOM is generally a value that reflects the physical form the medication is 
dispensed in such as "tab," "vial," "inhalator," and "jar." The pharmacy UOM is used in 

30 preparation 506 and in stocking and dispensing systems. The financial UOM is generally a 

value used to calculate the financial figures that appear on bills and invoices. The medication 
screening UOM is generally used when screening the medication. 
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Units of measurement defaults 544d can be specified using a check-box table where 
checkmarks are placed in a table correlating the various UOMs with the users of the UOMs. 
The infusion system 210 can use the same UOM for more one function. For example, the 
physician's UOM can be the same as the pharmacist's UOM. Setting defaults 544 include data 
necessary to coordinate the various UOMs. For example, UOM defaults 544d can include the 
multipliers and dividers necessary to create a one-to-one correspondence between the various 
UOMs. The UOM defaults 544b can be changed to suit the desires of the individual clinicians. 
However, the one-to-one correspondence should be maintained by the patient care system 100. 
The infusion system 210 can be designed to maintain a history of medication unit defaults. 

The infusion system 210 can also include medication measurement suffixes. The 
medication measurement suffixes can default during order entry. The medication measurement 
suffixes can be common units of measuring a medication and can include units related to patient 
characteristics such as body surface area and weight. Medication measurement suffixes can be 
designated per drug, per order type, per dose, and per UOM. 

Building database 546 includes building databases and/or portions of a single database 
such as, but not limited to, preparation area 546a, additive information 546b, solution 546c, pre- 
mix definitions 546d, favorites 546e, timing override reasons 546f, flow rate override reasons 
546g, translation tables 546h, flow rate description 546i, equipment and routing information 
546j, and message trigger 546k. 

Timing override reasons 546f include displayable reasons for modifying the timing of 
infusion orders. For example, timing override reasons 546f can include a stylus-selectable 
reason for digital assistant display 1 18a for administering an infusion order at a time other than 
the time specified in the original infusion order. If the clinician 116 administers a medication 
outside the ordered administration time tolerance 542c, the clinician 116 can be required to 
choose a reason code for the modification from displayed reasons 1008f (FIGURE 11). 
Examples of other reason codes include, but are not limited to, PRN administration reason codes 
and codes for stopping an infusion. 

Medications 124 and/or infusion orders can have flow rate tolerances, including system 
flow rate tolerances 542b. The infusion system 210 can include flow rate override reasons table 
546g. Flow rate override reasons 546g are notations that the clinician 116 can choose from, 
and/or supply, if the clinician 116 needs to change the flow rate beyond the bounds defined by 
the flow rate tolerance 542b. The infusion system 210 can include a defined message trigger 
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546k indicating whether or not a message should be sent to the patient's physician if a clinician 
116 overrides an order-defined flow rate tolerance. The infusion system 210 can also include 
defined message triggers 546k indicating whether or not a message should be sent, and to whom, 
if a clinician 116 overrides a tolerance, such as flow rate tolerances 542b, defined at a level other 
5 than the order. 

The infusion system 210 can include translation tables 546h such as, but not limited to, a 
flow rate translation table, a varying ingredient translation table, and varying flow rate 
translation table. Flow rate translation includes translating an infusion order into a flow rate 
defined by volume/time where the order is originally specified in any way such as, but not 

10 limited to, dosage/time with a particular concentration, volume per unit of weight/time, dosage 

per unit of body surface area/time, and total dosage and duration. 

Varying ingredient translation includes translating a plurality of flow times of infusion 
orders with varying ingredients in separate infusion bags into the flow rate for the infusion bag 
currently being administered. Orders with varying ingredients include orders such as, but not 

15 limited to, sequencing orders. In sequencing orders, different bags have different ingredients 

and potentially different flow rates. 

Varying flow rate translation includes translation of infusion orders with varying flow 
rates into the flow rate for the current solution being infused. Varying flow rate orders include 
orders such as, but not limited to, bolus/basal, orders, tapering dose orders and alternating dose 

20 orders. 

The infusion system 210 can include predefined infusion flow rates 542b. The 
predefined infusion flow rates 542b can be associated with flow rate descriptions 546i to permit 
selection from a drop-down list as a shortcut from keying in the flow rate. 

Defined functions 548 include functions such as, but not limited to, preparation area 

25 function 548a, bag duration function 548b, verify override requests function 548c, duration to 

volume function 548d, duration to flow rate function 548e, and flow rate to drip rate function 
548f. The infusion system 210 can include a duration- to- volume function 548d to determine the 
amount to be infused per the infusion order. Flow rate to drip rate function 548f uses 
information about the medical device 330 to convert flow rates to drip rates. 

30 Determined settings 550 include settings such as, but not limited to, override authorities 

550a, flow rate precision 550b, volume precision 550c, and time precision 550d. The infusion 
system 210 can, if desired, determine the total volume of infusions and the flow rate(s) of the 
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infusion order. If these numbers are determined, it is desired to round the calculated values to 
flow rate precisions 550b and volume precisions 550c that are comprehensible to clinicians 116 
such as the physician, the pharmacist, and the nurse. Flow rate display precision 550b can be set 
to display the flow rate to a set number of decimal places. Various parts of the patient care 
system 100 can independently determine the precision for displayed flow rates. For example, 
the infusion system 210 can display to one decimal place for an adult treatment location, and to 
three decimal places for a neonatal treatment location. The flow rate precision 550b reflects the 
service in which the clinician's patient(s) are located. The flow rate(s) of the infusion order can 
be rounded to a system-defined precision. The precision can be same for all infusion orders or be 
dependent on the patient's service. 

Volume display precision 550c can similarly be set to display infusion volumes to a set 
number of decimal places. Settable time precision 550d can be used to calculate the 
administration duration period based on flow rate if the infusion is a single dose infusion or an 
intermittent infusion. The total volume of each infusion bag calculated is rounded according to 
the volume precision 550c. The administration time is rounded by the infusion system 210 
according to the set time precision 550d. The time precision 550d can be the same for all 
infusion orders regardless of the patient's service or may be service-specific. 
Order Creation 

FIGURE 8 is a block diagram showing functional components for infusion order 
creation 504 of FIGURE 6. Infusion order creation 504 includes functional blocks for creating 
infusion orders. Infusion order creation 504 includes entering information 560, calculations 562, 
checks 564, and overrides 566. Entering information 560 can include functions such as, but not 
limited to, identifying the order type 560a, identifying the medications 560b, identifying the 
dose 560c, identifying the diluent 560d, identifying the flow rate 560e, and identifying the 
infusion site 560f. 

Infusion order creation 504 is linked to infusion bag preparation 506, infusion bag 
delivery (path 530), medication administration 512, and infusion order modifications 514. 
Infusion order types 560a include order types such as, but not limited to, single dosing, load 
dosing, intermittent dosing, and continuous. Continuous infusions include alternating infusions, 
sequencing infusions, tapering infusions, and titrating infusions. Upon selection of the first 
medication 560b in an infusion order, an infusion order type 560a form for the medication may 
default. The ordering clinician can have the option of selecting a different order type. The dose 
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560c and unit of measure 544d can also default. The unit of measure 544d can be correlated 
with the medication and/or the dose 544c. The infusion system 210 can include a default 
diluent, or several default diluents, for the medication. One default can be identified as a 
preferred diluent. A description can be associated with the diluent to assist the ordering 
clinician to decide which diluent to select. The diluent description can include a reference 
avoiding use of a particular diluent if a patient is hypertonic. 

The infusion system 210 can also allow additional infusion order subtypes 560a based on 
the previously mentioned infusion order types. Additional infusion order subtypes 560a can 
include, but are not limited to, TPN infusion orders, chemotherapy continuous infusion orders, 
piggyback infusion orders, and large volume parenteral infusion orders. The infusion order 
subtypes can be accessed from different parts of the infusion system 210 allowing sorting and 
filtering of infusion orders according to the subtypes. A special label format for each infusion 
order subtype can also be defined to further customize infusion order subtype orders and 
associated pharmacy workflow. 

When searching for a medication 124 during infusion order creation 504, the medication 
124 can be flagged as additive and/or a solution to aid the clinician 1 16 in creating the infusion 
order. This designation can be made in a medication identification file. 

Medication dose 560c can be determined in a number of ways such as, but not limited to, 
according to body weight, body surface area, and entered according to rate. When the flow rate 
is not entered, the infusion system 210 calculates the flow rate according to the dose and time 
period specified. The ordering clinician can specify the diluent 560d and its quantity. The 
pharmacy can provide a default for such parameters - see line 582 (FIGURE 6). A check 564 
can be performed to ensure the net concentration 564a for the medication 560b and the flow rate 
564b are appropriate. 

The infusion system 210 can identify and/or calculate flow rates 560e based on the 
patient's weight, body surface area, and/or a specified frequency and duration of therapy. The 
ordered flow rate 560e is checked 564b against the flow rate tolerances, such as system flow rate 
tolerance 542b. The net concentration of the medication 124 can be checked 564a against net 
concentration tolerances, such as the system net concentration tolerance 542a. 

In an embodiment, flow rate 560e can also include displaying descriptions of default 
flow rates to facilitate the entering of orders. Flow rate 560e can reference flow rate 
descriptions database 546L 
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Calculations 562 can include calculating the dose based on patient weight and/or height 
(possibly provided by ADT interface 310), the drug amount, diluent volume, concentration, or 
rate. Calculations 562 can include, but are not limited to, calculating the flow rate, if not 
specified in the prescription, the bag quantity 562a or number of infusion bags required for a 
5 specified period of time, the time period over which each infusion bag is to be administered, and 

the total volume of each infusion and infusion bag based on the concentration of the ingredients 
in the solution. Flow rates, volume to be infused, and/or duration can be modified. If modified, 
the infusion system 210 automatically calculates dependent quantities, based on calculations, if 
the maximum dosage for the ingredients in the concentration would be exceeded as identified in 

10 the ingredient's medication file, the patient care infusion system 210 alerts the pharmacist and/or 

clinician 116 and can ask for a reason code for the adjustment. 

Calculations 562 can include calculations such as, but not limited to, bag quantity 
calculations 562a, translation calculations 562b, duration to volume calculations 562c, and flow 
rate to drip rate calculations 562d. Checks 564 include a variety of checks that an infusion order 

15 can be subject to. The checks include checks such as, but not limited to, a net concentration 

check 564a, a flow rate check 564b, an administration time check 564c, a duration check 564d, 
and an infusion site check 564e. If an infusion order fails a check 564, the clinician 116 may be 
able to override the check. Overrides 568 can include overrides such as, but not limited to, a net 
concentration override 568a, a flow rate override 568b, an administration time override 568c, a 

20 duration override 568d, and an infusion site override 568e. Overrides 568 can generate 

messages 520 for the physician and/or the pharmacy. The infusion system 210 can distinguish 
between system-wide and subsystem overrides in determining whether it is necessary to 
generate a message 520. 

Overrides can include an indication of whether clinicians have the authority to override a 

2 5 tolerance. For example, flow rate override 568b can provide an indication of whether the 

clinician entering the infusion order has the authority to override the system flow rate tolerance 
542b. This indication can apply to the patient care system 100 or a subsystem. Duration 
override 568d can provide an indication of whether the clinician 116 entering the infusion order 
has the authority to override the system duration 542d. This indication can apply to the patient 

30 care system 100 or a subsystem. Overrides 566 also include displaying of reasons for the 

override 568f. Reasons for the overrides 568f can be selected by the clinician 116 from drop- 
down menus. 
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The result of the infusion order creation 504 is an infusion order 702. Infusion order 702 
can include an infusion schedule 704. The infusion system 210 can look ahead a period of time 
and generate the infusion schedule 704 - so long as the infusion order 702 is active - for infusion 
bag filling for that time period, or longer if specified on demand. The ordering clinician is not 
5 required to specify an end-date for the infusion order. The infusion system 210 can include 

automatic scheduling of infusion bag delivery based on infusion system 210 defined tolerances 
542. 

Order Preparation 

FIGURE 9 is a block diagram showing functional components for infusion order 
10 preparation 506 of FIGURE 6. Infusion preparation 506 includes functional blocks for 

preparing infusion order 702 (FIGURE 8). Infusion preparation 506 can include, but is not 
limited to, determining preparation location 506a, scanning ingredients 506b, bag duration 
checking 506c, and bar code printing 506d for medication labels 124a. Bar code printing 506d 
can include the functions described above in reference to print label 326 (FIGURE 4). 
15 After infusion orders are entered into the infusion system 210, preparation instructions 

are routed to a preparation location. The preparation location depends upon the infusion 
system's 210 preparation program 506 and the infusion components. The infusion system 210 
can include adjustable databases, such as preparation area database 546a, that specify where the 
infusion order is to be prepared. The infusion order can be prepared in the pharmacy or in a 
20 remote location, such as on the floor or at the treatment location 106. The clinician 116 is 

guided through the preparation process, including bar code verification of ingredients, using 
event management information that can be displayed on digital assistant 118 or another device 
having a display. 

The medication label 124a identifies the ingredients and ingredient concentrations. The 
25 medication label 124a can be printed in any location. The medication label 124a preferably 

includes bar code printing 506d. Bar code printing 506d can include printing a bar code label 
124a for each infusion bag. The label 124a assists in ensuring that the correct medication is 
administered at the correct times and/or in the correct sequence. Alternating and sequencing 
infusion orders are particularly vulnerable to sequencing and timing errors. Bar code printing 
3 0 506d can include printing a unique bar code label for every bag in infusion order 702. Bar code 

printing 506d can also include printing a bar code label 124a that uniquely identifies the 
combination of ingredients in an infusion bag and the concentration of those ingredients. The 
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bar code for medication 124 can include a prefix, a suffix, and the national drug code (NCD). In 
an embodiment, the bar code can also include a lot and expiration date. Alternatively, a separate 
bar code can be provided to include the lot and expiration date. Other embodiments of the bar 
code, including active or passive RFID tags, magnetic strips, etc. can be used. 
5 Medication Administration 

FIGURE 10 is a block diagram showing functional components for medication 
administration 512 of FIGURE 6. Medication administration 512 includes functional blocks that 
are used to administer the medication to patient 1 12. Medication administration 512 can include 
reading a medication bar code 512a, reading a patient bar code 512b, running an expiration 

10 check 512c, providing titrate notification 512d, providing a flow rate to drip rate display 512e, 

providing "as needed" infusion initiation 512f, downloading operating parameters 512g, and 
time monitoring 512h. The infusion system 210 can also translate orders that may have more 
than one flow rate, such as tapering and alternating orders, into the flow rate for the infusion bag 
currently being administered. The infusion system 210 can also translate orders having infusion 

15 bags with different ingredients, such as sequencing orders, into the flow rate for the infusion bag 

currently being administered. 

Upon administering the medication 124, the clinician 116 scans the medication label 
124a. The infusion system 210 includes scanning the bar-coded label 124a when initiating the 
administration of the infusion order, when changing flow rates, changing bags, and/or stopping 

20 the infusion order. Infusion system 210 verifies that the infusion bag having the bar-coded label 

should be administered at that time and is for patient 112. The history of the medication 
administration, including flow rates and volumes administered, can be captured and maintained. 
Some infusion orders require hanging of an infusion bag with the intent of only a partial, 
specific amount of the infusion bag to be administered. The infusion system 210 allows a 

2 5 clinician 116 to order an amount of an infusion bag to be administered. Most infusion pumps 

have the ability to define the volume to be administered or the flow rate and time period. Once 
this time has elapsed, the infusion pump will automatically prevent further administration. 
Infusion system 210, as a reminder to the administering clinician, provides a message on the 
medication label 124a that it is to be partially administered and the appropriate volume to be 

30 administered. 

Flow rate to drip rate display 512e uses data generated by flow rate to drip rate functions 
548f to provide the administering clinician with drip rates for the current infusion bag. During 
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medication administration 512, the clinician 116 can check on the flow rate and other operating 
parameters using the digital assistant 118. Flow rate modifications 1002b (FIGURE 11) are 
communicated in real-time. 

The infusion system 210 can include PRN or "as needed" infusion initiation 512f. "As 
needed" infusion initiation 512 causes the creation of a new active order and the preparation of 
the PRN medication. This option can include prompting the clinician 116 to select a PRN 
infusion from a list of anticipatory PRN orders placed for the patient and defaulting the 
requested infusion bags to one. The clinician 1 16 can have the authority to modify the requested 
quantity of infusion bags. 

Downloading of operating parameters 512g can include determining whether the patient 
identifier associated with the medical treatment and/or the patient identifier retrieved from the 
wristband 112a, is the same as the patient identifier associated with the medical treatment at the 
central location. The determination often is made by the first computer, for example, the first 
central server 109. If the infusion system 210 determines the various patient identifiers are not 
the same, the system can generate an alarm message 520. If the infusion system 210 determines 
the various patient identifiers are the same, the infusion system 210 can download the operating 
parameters directly to the medical device 332. The infusion system 210 can send the operating 
parameters to a medical device 332, such as infusion pump 120. 

One benefit of the system program 210 is that the operating parameters for the medical 
device 332 do not have to pass through digital assistant 1 18, or any other computer in the remote 
location, prior to the operating parameters being available to program the medical device 332. 
Bypassing computers at the remote location eliminates a potential source of errors in 
administering medication 124 to a patient 1 12. The operating parameters for the medical device 
332 can be sent "directly" to the medical device 332 assuming the various verifications are 
achieved. In this context, "directly" means that the operating parameters can be sent to the 
medical device without passing through the digital assistant 118, or any other computer in the 
remote location. 

In another embodiment, the infusion system 210 can include an additional block (not 
shown) where the central computer accepts a second medication identifier. The clinician 116 at 
the remote location can enter the second medication identifier. The second medication identifier 
can be a revised first medication identifier. For example, the second medication identifier can 
be part of the prescription or electronic physician order entry that is the source for the first 
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patient ID and the operating parameters. The infusion system 210 can then confirm the first and 
second medication IDs are equivalent prior to sending the operating parameters to the medical 
device. The second medication ID can be replaced by a revised first medication ID between the 
time the prescription is entered and the time the medication 124 arrives at the treatment location 
106. The infusion system 210 will then sound an alarm if the second medication identifier is not 
equivalent to the first medication identifier that was included in the medication label 124a. In a 
further embodiment, the infusion system 210 can include an additional block (not shown) where 
the operating parameter is used to program the medical device 332. 

Various blocks of the infusion system 210, such as block 512, can include displaying 
treatment information on the digital assistant 118. This can include displaying information that 
mirrors the information on display 120c of infusion pump 120. The information on display 120c 
of infusion pump 120 can be supplemented with information about the patient 112, the patient 
location, and the infusion order. This information can include information regarding multiple 
channels of infusion pump 120. The displayed information can include information such as, but 
not limited to, personality, prompt line, status line, operating icons and pump head display. 
Operating icons include falling drop, stop sign, flow check piggyback, and delay start. The 
pump head display includes information such as the drug label and the infusion rate. Those 
having ordinary skill in the art are familiar with the displayed information and operating icons 
described above. 

The infusion system 210 time monitoring 512h calculates the time remaining for an 
order to be completed and the volume of an infusion order that remains to be administered. 
When the clinician 116 uses the infusion system 210 to administer the infusion order, to make 
flow rate changes, and to check on the status of an infusion, the infusion system 210 calculates 
time and volume remaining to be administered and indicates if the calculation indicates a partial 
bag will be used. For example, on the last bag of an order that is to be stopped before the full 
volume is administered, and/or on a bag within an order that must be changed before the full 
volume is administered, the clinician 1 16 is alerted on digital assistant 1 18 and/or cart 132. The 
alert can include a message such as, "Please only administer 150 ml." 

Time monitoring 512h includes tracking any modifications made to the flow rate using 
bar code scanning. The pharmacy is alerted in real time to adjust the preparation 506 of the next 
required infusion bag according to the modification. Monitoring of preparation 506 and 
medication administration 512 allows for a just-in-time delivery of medication 124. Just-in-time 



Attorney Docket No. 



(1417G P1047) 



67 

delivery reduces wastage attributed to discontinued or changed infusion orders. Monitoring 
also ensures patient 112 safety. 

For titrate PRN orders, the clinician 116 is automatically notified of required flow rate 
changes if the titration conditions in the order indicate that the flow rate must be changed. The 
5 infusion system 210 includes defined functions for calculating a conversion of flow rates to drip 

rates 548f. The infusion system 210 defined values can be adjustable. The infusion system 210 
can include automatic translation of flow rate to drip rate 548f to assist the clinician 116 during 
administration of the treatment. 
Order Documentation and Modification 

10 FIGURE 11 is a block diagram showing functional components for infusion order 

documentation 1012, and the infusion order modifications 514 and messaging 520 of FIGURE 
6. Modifications 514 include functional blocks used to modify existing infusion orders. 
Modification 514 can also be viewed as creating new orders to replace existing infusion orders. 
Modification 514 can include modification changes 1002, generally all ordering options for new 

15 orders 1004 are available, rec hecks 1006, recheck overrides 1008, and new flow rate to new drip 

rate display 1010. Infusion order modifications often lead to documentation 1012 and 
messaging 520. Modifications 514 include the functions described in reference to prescription 
modification module 336 (FIGURE 4). However, modifications 514 are also accessible from 
other portions of the patient care system 100 such as, but not limited to, prescription entry 324, 

20 prescription activation 306, and prescription authorization 308. 

Modifications 514 include modifying the duration 1002a, modifying the flow rate 1002b, 
using a new infusion site 1002c, identifying reasons for modifications 1002d, identifying the 
volume of an infusion bag 1002e, and processing stop orders 1002f. Clinicians 116 can also 
change an infusion rate without an order if the patient 112 is complaining of discomfort or to 

2 5 facilitate fluid balance, such as when the patient 1 12 is vomiting. 

Modification changes 1002 include identifying a new duration 1002a, identifying a new 
flow rate 1002b, identifying a new infusion site 1002c, identifying a reason for a modification 
1002d, identifying the volume remaining in the infusion bag 1002e, and stop orders 516. The 
ordering options available during initial infusion order creation 504 are generally available for 

30 modifying the infusion order. Ordering options available during initial infusion order creation 

504 include those shown in FIGURE 8. Rechecks 1006 and recheck overrides 1008 are 
analogous to checks 564 and overrides 566 that are described in reference to FIGURE 8. New 



Attorney Docket No. 



(1417GP1047) 



68 

flow rate to new drip rate display 1010 assists the clinician and minimizes the possibility of 
errors during medication administration 512. The modified infusion order can lead to a 
modified infusion schedule. 

Flow rates are frequently modified at the treatment location 106 for reasons such as to 
5 catch-up without changing the schedule for preparation when the infusion has been inadvertently 

stopped for a short time period. Such modifications may not require new infusion schedule 704 
to be communicated to the pharmacy. In other cases, the new schedule 704 should be 
communicated to the pharmacy or other preparation staff. Flow rate modifications 1002b trigger 
infusion order scheduling changes and/or messages 520 for appropriate clinicians 116. 

10 When a clinician 1 16 enters a flow rate modification 1002b into the infusion system 210 

at treatment location 106, the clinician 116 can also elect to have the infusion schedule 704 
recalculated and sent to the pharmacy. The clinician 116 has the option of requesting new 
medication labels 124a to be printed by bar code printing 506d module. The new medication 
labels 124a include data reflecting the new information for any of the previously prepared 

15 infusion bags. 

The infusion system 210 and/or the clinician 116 can request a modification to the 
infusion site 1002c. The site can be selected from a list of anatomical representations on a 
computer screen. The clinician 116 can be required to identify a reason for the modification 
1002d. Reasons stored in databases such as, but not limited to, override reasons for timing 546f 

20 and override reasons for flow rate 546g, can be displayed for easy identification by the clinician 

116. There can be a separate hard-coded reason for physician-ordered modifications. For 
physician ordered modifications, the clinician 1 16 can be requested to identify the physician. 

Prior to implementing the modification, the volume remaining in the current infusion 
bag is identified 1002e. The clinician 116 can be offered the option of accepting a volume 

25 calculated from a displayed value of pre-modification flow rate and/or volume. 

If desired, the current infusion can be stopped 1002f. If stopping the order is not 
required, for example the same infusion bag can be used with a new flow rate and/or a new 
medication added, the old flow rate can be identified and compared to the modified flow rate. 

Any infusion bags that were previously prepared can be checked for expiration based on 

30 the new infusion schedule 704. When an infusion order is resumed following either a temporary 

stop or a hold order, the expiration check can be done regarding expiration of solutions that have 
already been prepared. 
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The new infusion schedule 704 is used to control the preparation 506 in the pharmacy or 
other preparation site. A system default 544 can be set for whether or not any prepared bags 
should be credited to the patient 112 through the billing interface 312, and whether or not they 
should be credited to inventory. 
5 Infusion order changes 1002 include all ordering options available 1004 for new orders. 

The modified flow rate can be rechecked 1006 for rules and tolerances such as, but not limited 
to, net concentration 1006a, flow rate 1006b, administration time 1006c, duration 1006e, and 
infusion site 1006f. Overrides 1008 can be available for modifications that are outside of 
tolerances. The infusion system 210 can display reasons 1008f for overrides and for 

10 administering medications at times other than that specified in the original order. The clinician 

116 can be required to identify a reason for the modification. 

The infusion system 210 can offer the clinician 116 a display indicating the modified 
drip rate associated with the modified flow rate 1012. The displayed information can be 
calculated by the flow rate to drip rate 548f defined function. The infusion system 210 can also 

15 be provided with descriptions of typical infusion tubing used within the infusion system 210 for 

use in calculating drip rates. 

A modification results in the infusion system 210 validating the expiration of the 
infusion bag and providing a message to the clinician 1 16 if the infusion bag expires prior to the 
completion of the order. The message can request that the clinician 1 16 contact the pharmacy. 

2 0 The validation of the expiration of the infusion bag for solutions such as, but not limited to, 

premixed solutions and solutions manufactured outside of the infusion system 210, may include 
parsing the scan code. 

Flow rate override 1008b can provide an indication of whether the clinician 116 
modifying the infusion order has the authority to override the ordered limit without requiring 
2 5 approval for a new infusion order. This indication can apply to the patient care system 100 or a 

subsystem. 

Documentation 1012 captures infusion order information in real-time. Documentation 
includes documenting multiple infusions being administered at the same time and infusion 
modifications such as, but not limited to, duration changes 1012a, flow rate changes 1012b, 
30 volume changes 1012c, and infusion site changes 1012d. 

The infusion system 210 can assist the clinician 1 16 in capturing all changes in flow rate 
as the changes are occurring. The clinician 116 can change the flow rate as called for in the 



Attorney Docket No. 



(1417G P1047) 



70 

order, such as to decrease a morphine infusion flow rate from 4 ml to 2 ml. Though the infusion 
system 210 may recognize the change as a new order, the infusion system 210 may be 
configured to avoid duplication so that the modified order does not result in the generation of a 
new bag. 

Documentation 1012 includes the ability to document changes such as, but not limited 
to, an infusion that is stopped temporarily, discontinued, and/or restarted. The clinician 116 
may stop infusion for a variety of reasons, such as the infusion site having been compromised, 
the infusion has been dislodged, and/or the infusion may be heparin/saline locked to facilitate 
the movement of patient 112. The infusion can be resumed when a new site/infusion has been 
reestablished. However the length of time this may take is variable and is generally recorded by 
the infusion system 210. 

Government regulations often require tracking of every step in the process of infusion 
administration. Infusion system 210 allows the administering clinician 116 to document flow 
rate modifications on a digital assistant 118, or other computer device, by scanning the 
medication label 124a and adjusting the flow rate 1002a based on a tolerance, such as a 
tolerance created by set tolerance 542. A flow rate modification 1002b corresponds in real time 
with the associated pharmacy's infusion schedule 704 to ensure just-in-time inventory 
management of infusion bags to the patient treatment area 106. Documentation 1012 may allow 
order backdating under some circumstances. 

The infusion system 210 includes the ability to document the infusion site 1012d and 
multiple infusions 1012e for multiple infusion sites. In many situations, a patient 112 can have 
multiple medications 124 and "y-ed" infusions so that the some infusions are running into one 
site and other infusions are infusing into another site. For example, morphine infusion, 
antibiotics and normal saline infused into the right arm (site 1) and TPN and 2/3 & 1/3 running 
into a double lumen CVL (site 2). The infusion system 210 allows clinician 116 to document 
which site the various fluids are infusing through. In treatment locations 106, such as intensive 
care units, many more than two infusions may be running into one line or one lumen. Clinicians 
1 16 are able to indicate which lumen of a CVL the infusion or medication is running into. 

The infusion system 210 includes the ability to document the site location 1012d for 
infusions and any site location changes. Infusion sites are frequently changed due to occlusions 
or policy. Therefore, clinicians 116 must document a change in the site location if an infusion 
becomes dislodged and was subsequently restarted. 
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The infusion system provides for centralized device configuration. Operating 
parameters for medical devices, such as infusion pump 120, often include defaults and/or 
tolerances. The defaults and/or tolerances can reside in the infusion system 210, for example 
flow rate tolerance 542b, and/or in a memory associated with the device 332. For example, 
5 infusion pumps 120 can include a database having a table of medications having associated flow 

rate tolerances. If the clinician 116 enters a flow rate that is beyond the associated flow rate 
tolerance, the clinician 116 is warned and then can be allowed to proceed, or prohibited from 
proceeding. Devices 332 such as heart rate monitors can also have configurable tolerances for 
alerts. In addition to alerts, many other characteristics can typically be configured for devices 
10 332 such as: network name, IP address, polling frequency, and colors. The infusion system 210 

includes configuring medical devices 332 individually or in groups from one or more central 
computers. 

System configuration parameters can be defined for a first type of medical device. The 
system configuration parameters are sent and accepted by the first type of device unless the 

15 particular first type of device has more specific configuration parameters that apply to that 

particular first type of device. For example, a first plurality of a first type medical device can be 
located at general care treatment locations. A second plurality of the first type of medical device 
can be located at an intensive care treatment location. The general care treatment location may 
not have specific configuration parameters while the intensive care treatment location does have 

2 0 specific treatment parameters. System configuration parameters will apply to all of the first type 

of medical devices throughout the infusion system 210, i.e. the devices in the general care 
treatment locations, unless specific configuration parameters apply, e.g. the intensive care 
treatment location. 

For each type of device, specific configuration parameters that apply to all devices of 

2 5 that type across a particular grouping of the devices override the system configuration 

parameters if a particular device belongs to the group having such a definition, unless the 
specific configuration parameters are overridden at an even more specific level within the 
infusion system 210. The groups might be defined as a clinical service, a nursing unit, and/or a 
combination of service and nursing unit. 

3 0 For each type of device, the user can define sets of configuration parameters that apply 

to all devices of that type being used for operations with specified ranges of attributes that 
override any other definition. In a hospital, the operations might consist of infusion orders and 
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the attributes might include patient weight, drug, patient disease state, and patient acuity. 

Devices can be identified as part of a general group, a specific group, and/or be 
associated with a particular patient by including the device address in a table in a database. 
General or specific configuration parameters can then be sent to the device according to the 
5 identification of the device. The specific configuration parameters can then be read back to the 

infusion system 210 and compared to the originally sent configuration parameters to verify the 
original configuration parameters were correctly received by the device 332. If the 
configuration parameters were not correctly received, the infusion system 210 can provide a 
message 520 identifying the discrepancies or the communication failure. 

10 The infusion system 210 can detect changes to configuration parameters made at the 

device, rather than through a central computer, and send a message and/or alert 520. The 
infusion system 210 can also poll the devices to verify their configuration parameters. If system 
and/or specific configuration parameters change, the changes can be propagated to all devices 
332 identified in the system as belonging to the group according to the groupings identified in 

15 the infusion system 210. 

Throughout this document and the related claims, "central location" and "remote 
location" are relative terms to each other. A "remote location" is any location where a patient is 
receiving treatment through a controlled medical device, such as a patient treatment location 106 
where patient 112 is receiving treatment through an infusion pump 120. "Central location" is 

20 any location, other than the remote location, where parameters for operating the medical device 

are accessible such as, but not limited to, the location of the pharmacy computer 104 and the 
central system 108. In a typical arrangement, several remote locations, such as treatment 
location 106, are in communication with a central location. 

While the present disclosure has focused on the use of infusion pumps 120 within the 

2 5 system 210, it is understood that other medical devices may be used within the system 210 

without departing from the scope of the present invention. For example, various types of 
medical devices include, but are not limited to, infusion pumps, ventilators, dialysis machines, 
etc. An additional type of medical device is a micro-electromechanical system (MEMS) 
component. MEMS is a technology used to create small or tiny devices which can be less than a 

30 millimeter in size, though they can also be larger as well. MEMS devices are typically 

fabricated from glass wafers or silicon, but the technology has grown far beyond its origins of 
the semiconductor industry. Each MEMS device is an integrated micro-system on a chip that 
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can incorporate moving mechanical parts in addition to optical, fluidic, electrical, chemical and 
biomedical elements. Resulting MEMS devices or elements are responsive to many types of 
input, including pressure, vibration, chemical, light, and acceleration. The MEMS components 
can be a number of different elements including various types of pumps, a flow valve, a flow 
5 sensor, tubing, a pressure sensor or combinations of elements. These MEMS devices are smaller 

than conventional machines used for sensing, communication and actuation. As a result, it is 
possible to use them in places where mechanical devices could not traditionally be used. MEMS 
devices also work at a higher rate and consume less power than conventional devices. 
Additionally, MEMS technology has advanced to the stage that MEMS devices can be 

10 manufactured at a cost making it feasible to treat the devices as disposable or one-time use 

devices. MEMS devices are typically etched in silicon. It is further understood that MEMS 
may also describe other types of micro electromechanical system devices such as devices that 
are micro-molded in plastic. Thus, MEMS devices may include devices etched in silicon, 
molded in plastic or otherwise fabricated on a small scale. It should be understood that the 

15 MEMS element or pump can take a variety of different forms. For example, the MEMS element 

or pump can include be a disposable element such as a disposable peristaltic pump, volumetric 
pump, ambulatory pump, syringe pump or other type of disposable pump. The MEMS element 
can also be a micro-molded pump or element, or otherwise fabricated on a small scale. The 
MEMS element can also be a piezoelectrically actuated plastic element or pump. In certain 

2 0 embodiments, a flow sensor could be embedded into a pocket in the flow path of the disposable 

pump itself. It is also understood that the MEMS devices of the present invention application 
can be manufactured using Application Specific Integrated Circuit (ASIC) technology wherein 
electronics are etched on the same chip as the MEMS fluid structures. 

Accordingly, as explained in further detail below, one use of a MEMS component is as 

25 an in-line MEMS pump 5314, shown schematically in FIGURE 53. The MEMS pump 5314 is 

capable of pumping fluid contained in the IV bag 5320 through the tube 5312, out through the 
access device 5324, and into a patient. The MEMS component has a MEMS local electronics 
element attached thereto, and the MEMS electronics element connects with an external, durable 
MEMS controller, which can communicate with the present system 210 as does the present 

30 infusion pump 120 described herein. In one embodiment of a MEMS pump 5314, the MEMS 

electronics element 5332 is embedded therein and can preferably store MEMS parametric 
operational information. The MEMS controller, with its electronics and power source, may be 
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physically or wirelessly connected to the MEMS electronics element. In one embodiment, the 
parametric operational information may be loaded from the detachable MEMS controller 5338. 
Preferably, the pump element 5314 generates the fluid flow through a tube 5312 based on 
information stored locally within the MEMS electronics 5332. This information is preferably 
downloaded from a wired but detachable MEMS controller 5338. Further, the MEMS 
components may communicate with the system 210 via wireless communication. Additionally, 
the MEMS controller may provide a transfer of information to and from the system 210 to fully 
automate the control and interrogation of the MEMS components in the present system 210 
through a wireless or wired communication path. 

The use of MEMS or other emerging economical fabrication techniques provides an 
opportunity to add a MEMS element to a disposable line-set that provides additional 
functionality such as pumping, valving, and sensing. Some or all of the supporting local 
electronics could be included in a disposable portion of a line-set as well. For example, it may 
be preferable to include a memory chip that contains calibration information for a pump, 
pressure sensor and/or flow sensor, valve, or a combination of disposable elements. 
Disposability is desirable as it removes the need for costly sterilization of the components of the 
system between each subsequent application. 
Pop-Up Windows 

In an embodiment, the system can automatically provide clinicians with information 
associated with one or more medications via pop-up windows. Preferably, a medication table is 
entered into the central database 108b. The medication table can include the generic name of 
one or more medications, and any trade names associated therewith. Linked to each medication 
within the medication table are respective messages for display via pop-up windows. The 
messages can be defined by the health care facility, or predefined by the system provider. 
Preferably, the messages associated with each medication pertain to: 1) hazards associated with 
the medication, such as in handling or exposure thereto; 2) how the medication is to be 
administered by a clinician; 3) physician reference information about medication; 4) the 
appropriate pump channel for infusing the drug; and, 5) warnings about infusion set procedures 
such as opening a roller clamp for a piggyback infusion. 

The pop-up windows are displayed when a medication is selected or entered into a 
computing device such as: when the medication is being ordered by a physician via the CPOE; 
when the medication is being processed by the pharmacy or the like; and when the medication is 
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being administered to a patient by a clinician. In an embodiment, when the selection or entry of 
a medication has been made on a computing device at a remote location, the database within the 
central system 108 is accessed wherein at least one of the pop-up window messages associated 
with the medication is provided to the remote computing device for display to the clinician. 

Preferably, at least one of the pop-up window messages associated with a medication is 
provided for display upon the initiation of a specific step in the medication order, process, and 
administration procedure. For instance, upon entry of a medication order into a computing 
device such as the CPOE, a pop-up window is displayed with a message regarding physician 
reference information about the medication and, in an embodiment, another pop-up window can 
be displayed regarding hazards associated with the medication. Then, upon processing of the 
order by a pharmacy or the like, one or more pop-up windows are displayed on a computing 
device within the pharmacy 104 for providing general information about the medication, and 
possible hazards associated therewith. Next, when the order is being administered by a 
clinician, one or more pop-up windows are displayed on a computing device associated with the 
clinician (i.e., handheld 118) for providing information about administration of the medication, 
and, in an embodiment, possible hazards associated with the medication such as how the 
medication is to be handled. 

Preferably, the pop-up windows displayed on a computing device are specific to the step 
in the medication order, process, and administration procedure that is being carried out by a 
clinician. For instance, the pop-up window containing physician reference information is 
preferably not displayed to the nurse, via handheld device 1 18. Nevertheless, in an embodiment, 
the user or hospital can define when, and if, a pop-up window should be displayed when a 
medication is selected or entered into a specific computing device. 

It is also preferred that the pharmacy define when, and if, a pop-up window is to be 
displayed. For instance, pop-up windows are preferably not displayed for common medications. 
Instead, pop-up windows are preferably displayed for medications wherein the pharmacy or 
healthcare facility believes that the additional information within. the pop-up window will assist 
in the ordering, preparing, or administration of the medication. 
Administering A Medication 

A method of administering a medication 124 with the infusion system 210 is described 
below. The method includes the ability to modify the infusion order. The modifications include 
modifications to the flow rate, the infusion site, temporary stops to the infusion, restarting the 
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infusion, and hanging a new medication 124 container. The method includes: scanning a bar 
code associated with the patient 512b; scanning a bar code associated with the medication 512a; 
if the infusion is an admixture, validating the expiration 512c; selecting a reason for the 
modification 1002d; and recording the remaining volume of the infusion bag or accepting the 
value calculated from the previous volume and flow rate 1002e. The validation of the expiration 
512c of the infusion bag can include the use of an admixture table and/or a bar code. 

The reason for the modification may come from a defined table 546g. The reason for the 
modification may also include a hard-coded value for physician-ordered changes. When the 
hard-coded value is selected, the clinician 116 is prompted to select the physician from a list of 
physicians. The attending physician can be the default in the list of physicians. 

There may be a quick select feature to halt the administration of the medication 124, for 
example, stop order 1002f. If the quick select is not chosen, the following processes can be 
included: recording the flow rate and/or accepting the previous value for the flow rate - the 
previous value is displayed on the digital assistant display 118a, the infusion pump display 120c, 
and/or the medical cart 132; comparing the previous flow rate to the ordered flow rate - this 
comparison can be accomplished by using infusion system 210 or subsystem rules and 
tolerances; displaying appropriate messages; conversions between flow rates and drip rates can 
be displayed 1012 - the conversions can be calculated based on infusion system 210 defined 
drip-rate conversion tables 548f. The infusion system 210 typically uses descriptions based on 
the tubing used to make it easy for the clinician 1 16 to select the correct drip rate conversion. 

Changing the flow rate triggers the infusion system 210 to validate the expiration of the 
infusion bag(s) based on scheduled flow rate. If the solution expires before or during the 
administration, a message is sent to the clinician 116, such as "This solution will expire during 
the scheduled administration period. Please contact the pharmacy." If it is a premixed infusion 
bag and/or a customized infusion bag, the expiration is validated by parsing the scan code, if 
possible. The previous infusion site is accepted or a new infusion site location is selected from a 
list or a graphical anatomical representation. Then the schedule 704 is recalculated to implement 
pharmacy restocking. Infusion system 210 can include biometrics for identifying patients and 
clinicians 116. 

Prior to allowing a clinician 116 to access the infusion system 210, the infusion system 
210 accesses information related to the identity of the clinician 116. The infusion system 210 
can identify the clinician 1 16 by using a device, such as a bar code reader, to read the clinicians' 
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badge 116a. The system can also use biometrics to positively identify the clinician 116, to 
assure the clinician is an authorized user of the system, and to determine whether the clinician 
116 has authority to access portions of the infusion system 210. The infusion system 210 can 
require a combination of the clinician badge 116a, or other key, and a verified biometric match 
in order to grant the clinician 116 access to the infusion system 210. The system can also be 
configured to terminate access to the infusion system 210 when the clinician badge 116a is 
removed from the vicinity of the device used to read the clinician badge 1 16a, or other key. 

Biometrics is the technology and science of statistically analyzing measured biological 
data. One field of biometrics is that of determining unique physical characteristics, such as 
fingerprints. Biometrics makes it possible to identify individuals to digital systems, such as 
infusion system 210. A digital persona is created that makes transactions and interactions more 
convenient and secure. Biometric features for identification include features such as, but not 
limited to, fingerprint, face, iris and retina scanning, and voice identification. Biometric devices 
include a scanning or reading device, software to convert the scanned information into a digital 
format, and a memory to store the biometric information for comparison with a stored record. 
Software identifies specific matched points of data that have been processed with an algorithm 
and compares the data. Unlike passwords, PIN codes, and smartcards, the infusion system 210 
biometrics cannot be lost, forgotten, or stolen. 

The biometric scanner can be associated with the device for reading the clinician's badge 
116a. For example, the biometric scanner can be a thumb print reader on the handle of a bar 
code reader. In other embodiments, the biometric scanner and an electronic key reader can be 
located on the portable medicine cart and/or the medical device. When the clinician 1 16 places 
the electronic key within a specified distance of the medical device, a processor will know the 
specific individual electronic biometric identification file it should expect. The infusion system 
210 preferably prompts the clinician 116 to scan his biometric information. The biometric 
information is entered into the infusion system 210 with some type of biometric reading or 
scanning device. A one-to-one comparison is made between the scanned biometric information 
and the previously stored specific individual electronic biometric identification file. This one-to- 
one identity comparison is more efficient than comparing one-to-many identity files because it 
does not require searching an entire clinician database for a match. Instead, only one specific 
comparison is made. If there is a match, then the clinician 116 is granted access to the medical 
device 332. If there is no match, the clinician 1 16 is denied access. 
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Additionally, in another embodiment, the medical device does not have a controller. For 
example, the medical device may be a pumping unit that does not have a controller, but rather 
merely accepts control signals from a separate controller. In one embodiment, the controller for 
such a medical device can be the first central computer 109. Accordingly, the first central 
5 computer 109 may send control signals directly to the medical device for controlling the medical 

device. 

In another embodiment, after the infusion system 210 grants access to the clinician 116, 
the infusion system 210 terminates that access when the electronic key is removed from the 
biometric scanner, or the vicinity of the biometric scanner. The vicinity within which the 

10 electronic key must be kept can be predetermined and/or may be a variable and programmable 

infusion system 210 parameter. 

In one embodiment, the infusion system 210 includes an encrypted digital fingerprint 
template, a clinician's name, a login name, and a password. One technology for implementing 
the clinician identifier includes "IBUTTON 400" technology from Dallas Semiconductor 

15 technology. The infusion system 210 can be activated when the clinician places a finger on a 

fingerprint scanner. If the infusion system 210 finds a match, the infusion system 210 can 
request the clinician 116 login to the infusion system 210. If the infusion system 210 does not 
find a biometric match, the system does not allow the clinician 116 to access the infusion system 
210. 

20 In another embodiment, the database storing biometric information can be kept in the 

central system 108, the pharmacy computer 104, and/or the treatment location 106. At the 
treatment location 106, the database can be maintained in the portable cart 132, the digital 
assistant 118, and/or the medical device 332. Such distributed databases allow access to remote 
devices even if the network 102 is unable to communicate between the various locations. When 

2 5 network 102 communication is reestablished, the remote and central databases can be 

synchronized with any information modified at the other location so that both infusion system 
210 databases are properly updated. 

The infusion system 210 provides a closed loop infusion therapy management system. 
The closed loop begins with a clinician 116 order. Among other methods, the clinician 116 can 

30 enter the order through digital assistant 1 18 and/or medical treatment cart 132. The order is then 

available in real-time for pharmacy authorization 508 and physician authorization 510. The 
order is available in real-time as an electronic medication administration record (eMAR). The 
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eMAR is available to the clinician 116 for infusion administration. The infusion system 210 
automatically documents medication administration 512 and modifications 514 such as flow rate 
changes 1002b. Through the process of medication administration 512, the infusion system 210 
simultaneously adjusts infusion system 210 and/or subsystem inventory and billing 518. The 
5 infusion system 210 also provides event management and decision support data. The infusion 

system 210 is device independent, meaning that it can be run on workstations, wireless tablets, 
and handheld digital assistants 118. The infusion system 210 generally runs in real time, 
however, batch processing and or messaging can be used to coordinate various stages of the 
infusion system 210 processes. 

10 The closed loop infusion therapy management system includes infusion order entry 560, 

order preparation 506, and the availability of the status of the infusion. Infusion order entry 560 
can be through a number of means such as, but not limited to, the prescription entry module 324, 
the prescription modification module 336, and the pharmacy interface 316. Computer screen 
400 can be employed in entering the infusion order. The status of the infusion provides patient 

15 112 specific usage of infusions and alerts the pharmacy of the need for additional infusion bags. 

Clinician Interaction With The Infusion System 

Further, the infusion system 210 can use a login system to determine if the clinician 116 
has access to the infusion system 210. One example of an interface screen of a login system for 
an infusion system 210 is shown in the login screen 1903 of FIGURE 19. In that interface 

2 0 screen, the clinician 1 16 enters both a user name and a password, and clicks on the "Login" key. 

The system 210 conducts a check to confirm that the user name and password are valid for the 
system 210. If either the user name or the password is not valid, the system 210 will inform the 
clinician 116 that the login failed in the login screen 2005 shown at FIGURE 20. The clinician 
116 will then have the opportunity to reenter the user name and password to correct any errors. 
25 If the user name and password are valid, the clinician 116 will have access to the system 210. 

Additionally, if the clinician 116 is logged in to a digital assistant 118, but does not use it for a 
period of time, a security feature of the system 210 prevents the digital assistant 118 from being 
used further until the clinician 116 logs back in. 

The charge clinician may also login to the system 210. As explained in detail herein, the 

3 0 charge clinician is generally a supervisor or some person whom the clinicians report to. 

Additionally, the charge clinician may be a person who assists in workflow for the clinicians, or 
who assists in monitoring alarm or alert conditions. Typically, the charge clinician maintains a 
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supervisory or responsibility role over at least one unit. Thus, the charge clinician must login, 
with a login and password as explained above, and then select the units to be associated with the 
charge clinician. 

After the clinician 116 has completed the login process shown in FIGURE 19, and has 
5 been granted access to the system 210, the clinician 116 may perform several administrative 

functions. One such administrative function is to select a unit. As shown in the unit selection 
interface screen 2105 of FIGURE 21, the clinician 16 may select a unit from a drop down menu 
2107. In the example illustrated in FIGURE 21, the clinician has selected "Neurology ICU" as 
the unit. After the clinician 116 has selected the appropriate unit from the drop down menu 

10 2107, the clinician 1 16 can depress the arrow key 4809 to enter the selected unit. 

Another administrative function that the clinician may execute is to select the clinician's 
shift. As shown in select shift screen interface 221 1 of FIGURE 22, the clinician 116 may select 
either a standard shift or a customized shift. Several standard shifts which may be selected are 
provided in the drop down menu 2107 for that entry. If, however, the clinician 116 selects the 

15 customized shift, the clinician is requested to enter the start time and the end time for the 

customized shift. The clinician 116 may also enter a manual shift in the provided area 2255 and 
then tap the enter key 4809. 

A view patient interface screen 2313 is shown in FIGURE 23. In that screen 2313, after 
the shift has been selected, the clinician 116 may view the patients associated with the clinician 

20 116. The clinician 116 may also view the tasks associated with the clinician 116. Accordingly, 

a "to-do" list may be provided based on the patients, the clinician's tasks or both. Different 
levels of shading and/or coloring may be utilized to differentiate between the level of urgent care 
required for a specific patient. Additionally, various icons may be used in connection with the 
patients to provide the clinician 116 a quick understanding of the care required by a patient. The 

2 5 patient view interface screen 2313 of FIGURE 23 also provides the clinician 1 16 with the ability 

to add more patients at button 2315. When the clinician 116 selects the "Add More Patients" 
key 2315, the clinician may be provided with a list of additional patients. 

The clinician 1 16 may also be provided with a patient selection interface screen 2417 as 
shown in FIGURE 24. At this screen 2417, the clinician 1 16 may select patients to be added to 

30 the clinician's shift. The patients may be from the unit associated with the clinician, or the 

clinician may select to add patients from different units. The clinician 116 may also select the 
amount of time with which they will be associated with that patient. Further, the clinician 116 
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may also find more patients at key 2419. It is also understood that the clinician 116 may also 
remove patients from a shift at any time. 

The system 210 also provides messages to the clinicians 116 that are specific to the 
patients assigned to the clinician's shift. Typical messages may include items such as order 
5 profile changes and missed medication administrations. 

A patient information menu interface screen 2521, shown in FIGURE 25, is also 
available on the present system. The patient information menu screen 2521 provides a mini 
patient chart for the selected patient. The patient menu screen 2521 also provides the clinician 
116 the ability to link to items relating to the patient, such as: administer medications/infusions, 

10 stop infusion, resume infusion, titrate infusion, flow rate history, pump status, and remove 

patient from shift. The patient menu screen 2521 also has tabs for: Allergies and Ht/Wt, 
Medication History, and Lab Results. An example of an Allergies & Ht/Wt interface screen 
2521a is provided in FIGURE 25A. Typically this screen 2521a is displayed when the mini- 
chart is first opened. It displays information about the patient's drug and general allergies, and 

15 the last recorded height and weight of the patient. An example of a Medication History interface 

screen 2521b is provided in FIGURE 25B. Typically, this screen 2521b provides the clinician 
with a medication history of the patient within the selected look back period. The look back 
period may be adjusted by the clinician. Finally, an example of the lab results interface screen 
2521c is provided in FIGURE 25C. Lab results are made available in the system 210 through a 

2 0 lab interface. All available results are shown, and displayed in reverse chronological order. 

An infusion schedule interface screen 2623 for a patient is shown in FIGURE 26. This 
screen 2623 illustrates an infusion schedule for the selected patient. By clicking one of the 
identified orders, such as order 2625 for Morphine Sulfate on the infusion schedule screen 2623, 
the system 210 will link to the medication order interface screen 2627 shown in FIGURE 26A. 

2 5 Medication order screen 2627 provides a detail of order 2625 for the specified order (i.e., 

Morphine Sulfate). As part of the detailed order 2625, the therapy parameters 2629 are 
provided, as well as any warnings 2631 and the ability to link to additional information 2633. 

FIGURE 28 illustrates a patient profile infusion schedule interface screen 2835 wherein 
one of the scheduled infusions was missed. As shown in screen 2835, a "missed medication" 

3 0 icon 4837 is shown next to the schedule Morphine Sulfate infusion order 2839. By clicking on 

the "missed medication" icon 4837, the system 210 links the clinician 116 to a missed 
medication interface screen 2941 as shown in FIGURE 29. The missed medication screen 2941 
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requests the clinician 116 to enter, or select in the drop down menu, a reason 2943 for missing 
the medication. The missed medication interface screen 2941 also inquires of the clinician 116 
whether the medication schedule for the order 2839 should be adjusted. To adjust the 
medication schedule, the clinician 116 would select box 2945 on interface screen 2941. When 
5 the clinician 116 clicks on the drop down menu to enter select a reason 2943 for missing the 

medication, the drop down menu will expand as shown on interface screen 3047 of FIGURE 30. 
Typically, if the medication is no longer needed, the clinician will select the "Not Required" 
reason 3045. When the clinician 116 selects the "Not Required" reason 3045 for missing the 
medication, the system 210 removes the missed medication icon 4837 and inserts the "Not 

10 Required" icon 4857 as shown in the infusion schedule screen 3135 of FIGURE 31. 

When the clinician 116 is ready to provide a medication therapy or order for a patient, 
the clinician 116 will select the order 3225 in the schedule interface screen 3235, and then scroll 
down to the "Get Items" key 3249 as shown in FIGURE 32. After the clinician 116 selects the 
"Get Items" key 3249, in screen 3249 of FIGURE 32, the system 210 displays a medication 

15 interface screen 3351 as shown in FIGURE 33. In the medication screen 3351, the clinician 116 

has the ability to scan the medication selected from the medication depot as shown at the "Scan 
Depot" icon 3353, or to skip the scan depot block by selecting the "Skip Scan Depot" key 3355. 
When the clinician 116 scans an item, such as by scanning a bar code on the item, the item 
information is displayed on the clinician's PDA 118. An example of a scan screen 3465 is 

20 shown in FIGURE 34. When, for example, the clinician 116 scans a medication, the 

prescription 3467 is displayed in the scan screen 3465. If, however, the scanned item does not 
match the order for the patient, a scan error screen 3569, such as shown in FIGURE 35 will be 
displayed on the clinician's PDA 118. As shown on interface screen 3569, when a scanning 
error is detected the clinician 116 will be provided with an identification of the item to request or 

2 5 search for as shown on screen 3569. If a bar code cannot be scanned, for example due to a 

smeared or damaged bar code label, the data requested by the scan can be entered manually. 

If the selected medication is in the same therapeutic class as another medication that was 
recently administered to the patient, the clinician's digital assistant 118 displays a warning 
message. Similarly, if the item has already been retrieved by another clinician, the digital 

30 assistant 118 displays a message indicating such occurrence. 

If the order to be retrieved is a mix-on-floor infusion, the individual ingredients are 
identified on the digital assistant 118 and are to be retrieved by the clinician 116. After the 
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items are retrieved, the system 210 generates a bag ID and prompts the clinician 116 to print a 
label 124a. At this point the clinician 116 also mixes the ingredients. After the clinician 116 
prints out the label, the label is added to the bag and it can be scanned by the digital assistant 
118. 

5 Certain orders may be either on-call or on-hold. These orders are displayed on the 

patient profile screen, such as interface screen 2835 of FIGURE 28. Orders that are either on- 
call or on-hold are available for viewing only, and not for retrieval. These orders are 
subsequently activated as appropriate. 

The scenario may also arise where the clinician 116 has an item, including a medication 

10 item, that is not being used for a patient. Referring to interface screen 3657 in FIGURE 36, the 

clinician 116 has the ability to identify the reason for not administering a medication, such as: 
not being required due to a monitoring result, the patient being unavailable, or the medication 
being refused. If the patient is not already identified in the screen 3657, the clinician 116 can 
select 3661 the patient by scanning the patient or entering the patient's name. Additionally, the 

15 clinician 116 can select to return the medical item to the medication depot by keying the 

"Waste/Return" selection key 3663. For certain narcotics and controlled medications, two 
signatures (i.e., a second authorization signature typically in the form of a login and password) 
may be required both to initially obtain the medication, and to return the medication to the 
depot. 

20 The interface screen 3657 of FIGURE 36 also provides the clinician 116 with the ability 

to scan the patient ID to identify the patient. If the wrong patient is scanned, or if the patient ID 
does not scan properly, the system 210 displays a message that the scan is invalid. Further, if 
the clinician 1 16 is unable to administer the medication, the clinician will typically have to enter 
a reason 3659 for not administering the medication as shown in screen 3657 of FIGURE 36. 

2 5 Some reasons for not administering the medication are: the medication is not required due to a 

monitoring result, the patient is unavailable, or the medication is refused by the patient. 

After the clinician 116 has already verified the patient and the item or medication, a 
route verification interface screen 3771 is displayed. As shown in FIGURE 37, one example of 
a route verification screen 3771 assists the clinician 116 in verifying the route 3773, line 3775 

30 and site 3777. The medication therapy 3778 may also be provided in the route verification 

screen 3771. After the clinician enters the route 3773, line 3775 and site 3777, the clinician 116 
can select the compare button 4817 and the system 210 will verify that the entered data is 
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correct. 

Next, the clinician 116 can select the pump channel mode as shown in the interface 
screen 3881 of FIGURE 38. In the pump channel mode interface screen 3881, the therapy 3882 
is shown and the clinician 116 has the option to designate the therapy 3882 as a primary therapy 
5 3884 or a piggyback therapy 3883. Each channel of the pump has the ability to operate a 

primary therapy in addition to a piggyback therapy. After the pump channel mode has been 
selected, the clinician can conduct a pump channel scan. FIGURE 38A illustrates a pump 
channel scan interface screen 3885. In the pump scan screen 3885, the clinician 116 scans the 
medical device, such as by scanning a bar code corresponding to the pump channel 121 and then 

10 clicking on the arrow key 4809. 

After the clinician 116 has: (a) scanned the patient, such as on interface screen 2313 of 
FIGURE 23, (b) scanned the medication, such as on interface screen 3465 of FIGURE 34, and 
(c) scanned the pump channel, such as on interface screen 3885 of FIGURE 38A, the clinician 
116 can program the infusion pump and conduct a comparison of the programmed infusion 

15 pump parameters or settings to the parameters of the pharmacy order. 

Comparison of Device Settings and Orders 

A exemplar flowchart of a comparison process 5200 is provided in FIGURE 52. This 
process may also apply to programming the infusion settings remotely from the server. 
Referring to FIGURE 52, the comparison process 5200 is initiated at block 5202 after the 

20 clinician 116 has scanned the patient ED 112a, medication container or bag ID 124a, and the 

pump channel 121, as identified above. By scanning the patient, medication bag and pump 
channel, an association of the relevant baseline data is provided such that the system 210, and 
more specifically server 109, can conduct further analysis and comparison of this and additional 
data. First, however, the first central server 109 conducts a check at block 5204 to ensure that 

25 the scanned or entered data for the patient, medication bag and pump channel results in a valid 

association. If the three data items do not result in a valid association, the system 210 displays 
an error message at block 5206 and requests that the clinician 116 re-scan or re-enter the codes 
for each of the patient ID, bag ED and pump channel ED at block 5202. If the three data items 
result in a valid association at block 5204, the server 109 will also conduct a sequence, as 

30 explained below, to determine if the identified pump channel 121 is in the server's 109 database, 

and if it is available for use. 

After the pump channel ID has been scanned into the system 210, the first central server 
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109 conducts a check at block 5208 to determine if the selected pump channel 121 is valid. 
Various reasons for an invalid pump channel determination is that: the pump channel does not 
exist in the system, the selected pump channel is already in operation, etc. If the check of the 
pump channel 121 results in an invalid result, an error message is displayed and the clinician is 
5 alerted that an invalid channel has been selected. Until the clinician 116 rescans the pump 

channel and a valid channel is recognized at block 5208, the comparison process 5200 is 
precluded and the system cannot conduct the comparison as identified in block 5214. If, 
however, the check results confirm that the selected channel 121 is a valid channel, the system 
progresses to block 5212 to establish the appropriate links, as explained below. 

10 At some time during the comparison process 5200, the second central server 108a 

creates an XML message containing data relating to the patient ED and order ED. As shown in 
the flowchart for the comparison process 5200, the XML data may be created and transferred to 
the first central server 109, as identified at block 5210, at any point prior to block 5212. If 
however, the XML data received by the first central server 109 from the second central server 

15 108a is invalid or incomplete, the comparison process is precluded and the system does not 

allow the comparison process to proceed as shown in block 5214. Conversely, if the XML data 
relating to the patient ID and order ID is complete and valid, after the first central server 109 
receives the XML data from the second central server 108a, the comparison process 5200 
progresses to block 5212. 

20 At block 5212 the first central server 109 attempts to establish a link or association 

between the patient ID, the order ID and the pump channel 121. If the first central server 109 is 
not able to establish a link between the identified data at block 5212, the comparison process 
5200 is precluded and the system 210 does not allow the process to proceed as shown in block 
5214. Further, the system 210 displays an error message that some data is missing or 

2 5 inaccurate, and the system cannot conduct a comparison. If the first central server 109 properly 

establishes a link between the identified data at block 5212, the system 210 proceeds to block 
5216 wherein the clinician 116 is requested to press the compare button 4817 on the digital 
assistant 118. An example of the sequence of screens occurring at block 5216 is identified 
below. 

30 After the appropriate links have been established by the first central computer 109, the 

system 210 progresses to one of the comparison interface screens, such as comparison interface 
screen 3986 of FIGURE 39. In this comparison interface screen 3986, the system 210 provides 
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instructions to the clinician 116 to program the infusion pump prior to conducting any 
comparisons. Comparison may be made to ensure that the pharmacy parameters for the 
medication and the pump settings are in agreement. In a preferred embodiment, in the 
comparison process 5200 as identified herein, the system 210 conducts a rate comparison. The 
5 system may, however, conduct a single comparison or simultaneous multiple comparisons of 

any infusion parameter such as rate, volume, dose, etc. 

If the infusion is a primary infusion, the instructions are provided to click the "Compare" 
button 4817 on the comparison interface screen 3986 and then to wait for instructions prior to 
starting the pump channel. If the infusion is a piggyback infusion, the instructions are provided 

10 to press the start key on the pump 120 and then to click the "Compare" button 4817. In a 

piggyback infusion, if the clinician 116 presses the compare button 4817 at block 5216 prior to 
pressing the start key on the pump, the interface screen 4287 as shown in FIGURE 42 will 
typically be displayed providing the clinician with error instructions. 

Initially, prior to conducting a comparison the system 210 polls the server 109 to ensure 

15 that the communication link between the pump 120, server 109 and digital assistant 118 is still 

active. If the communication link is active the comparison process 5200 proceeds. If the 
communication link is lost, the comparison process is not able to proceed. 

Accordingly, after the clinician 116 has pressed the compare button 4817, the system 
210 proceeds to block 5218 as shown in FIGURE 52. At block 5218 the system 210 determines 

20 if the channel 121 is ready. For example, if the infusion has been identified as a primary 

infusion but the channel is already running, the system will default to block 5214 and display an 
error message that the system cannot conduct a comparison. Further, if the infusion has been 
identified as a piggyback infusion, and the start key on the pump has not been pressed, the 
system will default to interface screen 4287 of FIGURE 42 to inform the clinician 1 16 to press 

2 5 the start key on the pump before pressing the compare button 4817. 

The comparison process 5200 also checks the pump 120 to determine if the settings or 
operational parameters programmed into the pump 120 contains fresh data at block 5220. As an 
example, the system may require that the pump data have been programmed into the pump 
within a certain time limit (i.e., 5 minutes) prior to requesting the comparison. Such a time limit 

30 for determining if the data is fresh data can be set by the healthcare facility. If the data is not 

fresh data, the system will revert to block 5214 and display an error message that the data is 
stale. The system 210 will then request that the pump 120 be reprogrammed for the comparison 
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process can proceed. If the data is determined to be fresh data at block 5220, the system 210 
will execute the comparison at block 5222. The actual comparison of data is generally 
conducted at the first central server 109. As previously explained, the comparison is to 
determine if the parameters programmed into the pump conform with the physician's order. 
Additionally, or alternatively, the pump settings can be remotely programmed by the remote 
controller or server. 

After the comparison is conducted at block 5222, the system 210 determines if there is a 
match or mismatch at block 5224 and returns the results to the clinician 116 via the digital 
assistant. 

An example of a resultant comparison interface screen 3987 where the comparison 
results in a match is shown in FIGURE 39A, and identified at block 5226 in FIGURE 52. In this 
instance, if the pharmacy prescription parameters and the programmed pump channel settings 
match, the clinician 1 16 is instructed to start the infusion pump 120. 

An example of a resultant comparison interface screen where the comparison of the 
pharmacy prescription parameters and the programmed pump settings do not match at block 
5224, is depicted in the mismatch comparison interface screen 4087 of FIGURE 40 with the 
mismatch icon 4825 shown. If this result occurs the system 210 will require the clinician 1 16 to 
either accept the mismatch, as identified at block 5228, or reprogram the infusion pump at block 
5230 and conduct another comparison at block 5216. Typically, the parameters wherein the 
mismatch occurred will be displayed in the mismatch screen 4087. If the mismatch is accepted, 
it will be recorded in the system database 109 at block 5232. Further, if a mismatch is accepted 
at block 5228, the server 108a will navigate the clinician to the appropriate screen. 

FIGURE 41 displays an example of a comparison interface screen 4187 whereby the 
system 210 is not able to conduct a comparison because some of the data is not available. 
Specifically, in the example of FIGURE 41, the pump rate settings have not been entered into 
the system 210. Thus, the system 210 cannot conduct the comparison until additional data, such 
as the rate in this example, has been entered. Typically, the system 210 is not able to conduct a 
comparison if: an infusion is already running, the system cannot receive updated pump 
information, there is a system communication error, or there is missing data either from the 
programmed channel information or the pharmacy prescription information. Finally, the 
comparison screen 4287 of FIGURE 42 displays another scenario whereby the system 210 
cannot conduct the comparison until further steps are taken as indicated. Typically, this 
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interface screen 4287 is provided when the infusion is a piggyback infusion, and the clinician 
has pressed the compare button 4817 in interface screen 3986 of FIGURE 39, instead of 
pressing the start key on the infusion pump 120 prior to pressing the compare button 4817, as 
indicated in the instructions of interface screen 3986 of FIGURE 39. 
5 After the infusion pump has initiated a therapy, the clinician 116 is able to view on 

his/her digital assistant 118 the status of the pump in a pump status interface screen 4391 as 
shown in FIGURE 43. The pump status display 4391 displays a list of all currently active 
infusions for a given patient. Typically, one of five icons will be displayed in conjunction with 
an infusion in this screen: infusion running indicator 4807, infusion standby indicator 4810, 

10 infusion stopped indicator 4811, an unknown icon, and a delay icon. The pump status display 

4391 does not update in real-time while a current screen is being displayed; however, by tapping 
the refresh button 4819, the most current real-time pump status screen will be displayed. 

As shown in FIGURE 44, the clinician 116 is also able to view a flow rate history 
interface screen 4493. The clinician 116 can navigate directly to the flow rate history screen 

15 4493 by clicking on the flow rate history link on the patient menu interface screen 2521 shown 

in FIGURE 25. The flow rate history shows the history of programmed flow rate history 
changes for a current infusion on a given channel. Generally, the patient information associated 
with the channel is displayed, as well as the current prescription information for that channel. 
Further, after the clinician 116 has logged in on the digital device 118, selected the shift and 

2 0 selected the patients, the clinician 116 can perform a variety of tasks on the digital device 118, 

including but not limited to: recording an administered infusion, recording a stopped or resumed 
infusion, recording a discontinued infusion, viewing pump flow rate history as described above, 
viewing pump infusion status as described above, responding to pump alarms and alerts as 
described below, viewing messages/notifications and responding to messages/notifications. 

2 5 Specifically, with respect to recording an administered infusion, after the clinician 116 has 

scanned the item bar code, the patient bar code, and the pump channel bar code, the clinician is 
able to compare the programmed pump settings to the pharmacy-entered order as explained in 
detail above. Typically, the clinician 116 will then administer the infusion using the pump 120 
and record the infusion using the digital device 118. 

30 To start an infusion, the clinician 116 typically scans the patient's wristband bar code 

1 12a and scans the infusion bag bar code label 124a. When prompted by the digital device 1 18, 
the clinician 116 enters and compares the line, site and route for the infusion as shown in 
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interface screen 3771 of FIGURE 37. Next, in screen 3881 of FIGURE 38, the clinician 116 
selects a primary or piggyback infusion 3883, and scans the pump channel. The clinician 116 
then programs the pumps as directed by the physician order. When the pump 120 is 
programmed, the clinician 116 selects to conduct a pharmacy order and pump comparison 
5 check, as shown in FIGURES 39-42. If the programmed pump settings match the pharmacy- 

entered order, an interface screen such as screen 4287 will indicate a match, and the clinician 
116 can tap the OK button 4805 to accept the match. Finally, the clinician 116 will press the 
start key on the pump 120. The digital assistant 118 will then display the record administration 
results interface screen 4937 in FIGURE 49, and the clinician 116 can enter the appropriate 

10 result from the choices in the drop-down list. These steps can be repeated for additional patients 

and/or additional pumps or channels. 

Before administering a medication, the clinician 116 may be prompted to enter a 
monitoring parameter, e.g., a heart rate before administering dioxin, or a pain assessment before 
administering morphine. When a monitoring parameter is associated with a medication, each 

15 administration of the medication displayed on the digital assistant 118 has a link to an interface 

screen where the clinician 116 may enter a value. An example of such an order having a link 
5001 to the entry of a monitoring parameter is shown in the order displayed in FIGURE 50. 
After the monitoring parameter link 5001 is selected, a monitoring parameter entry interface 
screen 5003, as shown in FIGURE 50A is displayed. There, the clinician 1 16 may enter into the 

20 system 210 the requested information. 

Additionally, the system 210 may request the clinician 116 to monitor a cycle count, 
typically when retrieving narcotic or controlled medications from the medication depot. As an 
example, when the depot drawer opens to provide the narcotic or controlled medication, the 
digital assistant 118 may display a cycle count interface screen 5101 as shown in FIGURE 51. 

2 5 This interface screen 5101 prompts the clinician to count the units of medication currently in the 

bin or storage area, and then to enter this data in the field provided. The system 210 then 
compares this quantity to the expected count. If the cycle count does not match, the digital 
assistant 118 displays a message indicating the mismatch, and then displays the cycle count 
screen 5101 again. If the cycle count does not match again, the system 210 will record the 

30 discrepancy and appropriate measures may be taken. 

As circumstances require, a clinician may stop a running infusion before it has finished. 
This may be done either with or without a discontinue order in the system to stop the infusion. 
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Infusions that have been stopped may be resumed as circumstances require, such as titrating an 
order. When the discontinued infusion 4813 and running infusion icons 4807 are both displayed 
on the digital assistant 118, the clinician 116 is instructed to navigate on the digital assistant 118 
to display a list of all running infusions for the patient. An example of such a discontinue 
infusion interface screen 2727a is provided in FIGURE 27A. In FIGURE 27A the discontinued 
infusion order will be highlighted and indicated as being a discontinued infusion order. The 
clinician 116 will then scan the bar code on the solution container for the discontinued infusion, 
and then scan the patient's ID. Next, interface screen 2727b is provided on the clinician's 
digital assistant 1 18 as shown in FIGURE 27B. In interface screen 2727b the clinician can enter 
the time the infusion has been stopped, as well as the reason for stopping the infusion. The 
clinician 116 can then physically stop the infusion pump 120 by depressing the stop button on 
the infusion pump 120. 

A resume infusion interface screen 2727c is provided in FIGURE 27C. Infusions that 
are recorded as stopped, without an order to discontinue, may be resumed. To resume an 
infusion the clinician 116 must initially navigate to the appropriate interface screen on the 
digital assistant 118. By tapping on the stopped infusion icon 481 1 in the patient menu, a list of 
all infusions currently stopped for the patient will be displayed as shown in interface screen 
2727c of FIGURE 27C. A prompt is provided for the clinician to select the infusion to be 
resumed. The clinician 116 then scans the bar code on the solution container for the infusion to 
be resumed. The system 210 compares the scanned ID to those for the infusions currently 
stopped for the patient. After the system 210 compares the ID with those that are currently 
stopped for the patient, the digital assistant 118 prompts the clinician 116 to scan the patient's 
ID. The system 210 then confirms that the scanned ED matches the patient's ID, and the system 
210 will display on the digital assistant 118 the description of the scanned infusion and prompt 
the clinician 116 to select a facility-defined reason for resuming the infusion, as shown in 
interface 2121 & of FIGURE 27D. Once the reason is selected, the clinician 116 can restart the 
infusion at the pump 120 and then tap the arrow 4809 to continue. The system 210 records the 
infusion as having been resumed. 

As shown in the various screen shots/interfaces for the digital assistant 118, a variety of 
icons are utilized to assist the clinician 1 16. Many of these icons are shown in FIGURE 48. The 
patient list button 4801 is a key that, when tapped, allows the clinician 116 to navigate directly 
to the patient list screen, such as the patient list screen 2313 shown in FIGURE 23. The back 
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button 4803 is a key that, when tapped, returns the screen on the digital assistant 118 to the 
previous screen. The OK button 4805 is tapped to acknowledge data shown on the digital 
device 118. When the OK button 4805 is tapped the next screen is usually displayed. The 
infusion running indicator button 4807 indicates that a programmed infusion is now running for 
5 the selected pump 120 and channel. The infusion standby indicator 4810 indicates that a 

programmed infusion has been put on standby for the selected patient, pump 120 and channel. 
The infusion stopped indicator 4811 indicates that the programmed infusion has been stopped 
for the selected patient, pump 120 and channel. The infusion discontinue order indicator 4813 
indicates that a pharmacy-entered order will discontinue an infusion for the selected patient, 

10 pump 120 and channel. The physician's notes indicator 4815 indicates the presence of 

physician's notes for the selected patient, pump 120 and channel. The clinician 116 can tap the 
notes indicator 4815 to view the notes. The compare button 4817 is provided in various screens, 
and when tapped has the system 210 perform a comparison of the scanned item with the 
pharmacy-entered order, as well as additional comparisons. The refresh button 4819 is tapped to 

15 update and show the latest data on the screen. The exit button 4821 allows the clinician to exit 

the current screen, and return to the previously displayed screen. The enter button 4809 is also 
the OK button and is tapped to acknowledge and enter either data selected from choices within a 
drop-down list, or data manually entered in a field. The comparison match indicator 4823 
indicates that programmed pump settings match pharmacy-entered order information. The 

2 0 comparison mismatch indicator 4825 indicates that programmed pump settings do not match 

pharmacy-entered order information. The cannot compare indicator 4827 indicates that the 
system cannot compare the programmed pump settings to the pharmacy-entered order 
information. The pump alarm/alert indicator 4872 indicates that an alarm or alert condition is 
occurring. When the alarm/alert indicator 4872 is tapped, an expanded pump alarm and alert 

25 screen is displayed. On the alarm and alert screen, a red alarm/alert icon 4872 indicates an 

alarm condition, and a yellow alarm/alert icon 4872 indicates an alert condition. The alarm/alert 
silence button 4874 is tapped to temporarily silence the audible alert on the digital device 118. 
The loss of communication indicator 4833 indicates that the pump 120 and/or the hub 107 is not 
properly communicating with the system 210. A message accompanying this indication 

30 describes the steps to take to resolve the problem. The wireless module low battery alert 

indicator 4835 indicates that the hub 107 is presently running on a backup battery that has less 
than 30 minutes of battery power remaining. 
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The above disclosure relating to the setup and use of the digital assistant 118 has been 
discussed with respect to a clinician 116 performing these functions. It is understood, however, 
that these tasks may be performed by any hospital administrative or staff individual, whether or 
not that individual is a clinician 116. 
Emergency Notification Process 

Referring to FIGURE 12, there is shown a preferred embodiment of an emergency 
notification system 1200. A notifying party 1210 is in communication with a communication 
network 1220. One of skill in the art will appreciate the variety of communication networks are 
operable including, but not limited to, an Ethernet network, a coaxial cable network, a wireless 
local area network, and a wireless wide area network. Additionally, a variety of communication 
network protocols are operable, but not limited to, Transfer Control Protocol / Internet Protocol 
("TCP/IP"), Wireless Application Protocol ("WAP"), and User Datagram Protocol ("UDP"). 
Additionally, the communication network 1220 is operable as a part of a larger communication 
network; for example, the communication network 1220 may be a wireless communication 
network in communication with a wired communication network existing in, for example, a 
hospital. 

In communication with the communication network 1220 is a notifying party 1210. The 
notifying party 1210 may be a hospital clinician, for example, a nurse, doctor, hospital 
administrator, or security officer. The notifying party 1210 may also be a patient. Additionally, 
the notifying party 1210 may be an automated process, for example, a computer program or a 
medical device. The automated process acting as a notifying party 1210 may be programmed to 
broadcast an emergency notification across the communication network 1220 upon the 
fulfillment of a certain condition or an event. For example, the automated process may be 
programmed to broadcast an emergency notification upon the sensing of a patient condition. 

The emergency notification is received by one or more target parties 1230. Target 
parties 1230 may be clinicians, for example, doctors and nurses. The target parties 1230 may 
also be an emergency response officer or security officer, or an environmental hazard team. The 
target party 1230 may be any individual in communication with the communication network 
1220. The present embodiment provides the notifying party 1210 with the option of sending the 
emergency notification only to a certain target party 1230 or target parties 1230, or to all target 
parties 1230; the embodiment allows for the notifying party 1210 to choose which target parties 
1230 receive the emergency notification. 
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The target parties 1230 and notifying party 1210 are in communication with the 
communication network 1220. One skilled in the art will appreciate the variety of modes of 
communication 1240 which may provide for the notifying party 1210 and target parties 1230 to 
be in communication with the communication network 1220. For example, the mode of 
5 communication 1240 may be a wired connection, for example, a personal computer or 

programmable controller. The mode of communication 1240 may also be a wireless network 
connection enabled through a handheld computer or a cellular phone. 

Referring now to FIGURE 13, there is shown a notification interface 1300 from the 
perspective of the notifying party 1210. One skilled in the art will appreciate the variety of 

10 interfaces which will enable the notifying party 1210 to broadcast an emergency notification via 

the communication network 1220. The notification interface may be a website connected to an 
intranet or the Internet. The notification interface may also be activated by a cellular phone or 
other telephone, or by an electronic email. In one embodiment, the notification interface 1300 is 
a handheld computer of the type found widely commercially available. Examples include the 

15 Palm devices manufactured by PalmOne, Inc., the Visor devices manufactured by PalmOne, 

Inc., the Jornada devices manufactured by Hewlett Packard, Inc., the Axim devices 
manufactured by Dell, Inc., the Clie devices manufactured by Sony, Inc., and the PocketPC 
devices manufactured by Toshiba, Inc., Compaq and Symbol. 

In one embodiment, the notification interface 1300 comprises a menu 1330 listing one or 

2 0 more options 1340. For example, one notification option 1340 may allow the notifying party 

1210 to select a specific clinician or type of clinician to be the target party 1230 of the 
emergency notification. Another notification option 1340 may allow the notifying party 1210 to 
choose to cancel the emergency notification, in the event that the emergency notification was 
sent erroneously. Additional notification options 1340 may include entries for patient 

2 5 identification information, patient location, the type of the emergency, and the expected time for 

response. 

Referring now to FIGURE 14, there is shown one embodiment of a receiving interface 
1400 from the perspective of the target party 1230. Similar to the notification interface 1300, 
the receiving interface 1400 may be operable on a variety of different platforms and remain 

3 0 practicable under the principles of the present invention. In one embodiment illustrated in 

FIGURE 13, the receiving interface 1400 is a handheld computer. The interface 1400 includes a 
screen 1420 for displaying configurable information 2350. The information 2350 may include 
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emergency notification information such as patient identification, location of the emergency, the 
type of the emergency, and the expected time for a response. 

Both the notification interface 1300 and the receiving interface 1400 are optionally 
configured with a hotkey 1350, 1460. With respect to the notification interface 1300, the hotkey 
5 1350 may be configured to send an emergency notification containing information obtained 

automatically from the notification interface 1300 itself. For example, pressing the hotkey 1350 
on the notification interface 1300 may be configured to automatically send an emergency 
notification containing the information. 

Messaging & Notifications, Including Alarm/Alert Notifications 

10 The system provides for transmitting notifications and messages. Notifications may 

include, but are not limited to: patient status lists, alarms, alerts, infusion schedules, orders, 
overrides, warnings, therapy parameters, links to additional information, missed medications, 
route verifications, comparisons, flow rate information, physician notes, loss of communication, 
low battery, administration results, etc. The system also provides for displaying these and 

15 additional notifications. One way in which a notification is displayed is on the digital assistants 

118. Notifications may be provided to any one of numerous clinicians and/or charge clinicians. 

As explained above, one type of notification is an alarm/alert notification. In the present 
system, notifications may be escalated. A specific alarm/alert escalation process is shown in 
FIGURE 15. Typically, a notification process is provided to transmit notifications to any 

20 number of clinicians 116. The identified alarm/alert escalation process 1500 of FIGURE 15 

provides for notifying a series of clinicians via a clinician device 118 when an alarm or alert is 
active on a medical device such as an infusion pump 120. In a preferred embodiment, the 
clinician's device is a personal digital assistant ("PDA") 118, such as shown in FIGURES 1 and 
3, typically having a display 1 18a and an audible tone or sound generator 1 18c. For illustrative 

2 5 purposes only, the clinician's device will hereinafter be identified in this detailed description as 

a digital assistant 118. Further, the alarm/alert escalation process 1500 provides an escalation 
process when the clinician fails to respond to the alarm/alert notification on the digital assistant 
118. When an escalation process is started, a notification is provided to another or second 
clinician's digital assistant 118 as specified in the escalation procedure. While the alarm/alert 

30 notification is sent to the digital assistants 118, it is understood that typically the pump alarms 

and alerts can only be resolved at the pump. As explained herein, silencing of the alarm or alert 
at the digital assistant 118, such as in block 1580 of FIGURE 15, may or may not affect the 
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pump. 

The alarm/alert escalation process 1500 commences at block 1505 when at least one or 
both of an alarm or an alert condition is triggered at the medical device 120. In a preferred 
embodiment, shown in FIGURE 3, following the triggering of an alarm or an alert at the medical 
5 device 120, a signal containing data relating to the alarm or alert condition is generated and sent 

at block 1510 from the medical device 120, to the server 109. In a wireless environment, either 
a medical device 120 having a wireless transmitter is provided or a medical device 120 
connected to a wireless hub 107 is provided. In the latter example, shown in FIGURE 3, the hub 
107 receives signals from the medical devices 120 and converts the signals into a format suitable 

10 for transmission onto the system network 102 via wireless communication path or link 128. 

Further, if the hub 107 recognizes that the alarm, alert or other notification is a duplicate, it may 
discard the duplicate notification. The transmitted signal is received by a wireless access point 
114 within the healthcare environment. The wireless access points 114 provide an interface 
between the wireless communication paths (i.e., wireless path 128) and cable communication 

15 paths such as cable communication path 110 shown in FIGURE 3. 

After the server 109 receives the data relating to the alarm or alert condition, sent at 
block 1510, the server 109 conducts a precondition check at block 1515. The precondition 
check 3030 may include: associating the alarm or alert condition at the medical device 120 with 
a specific patient; associating the patient with a primary clinician, also referred to as a first 

2 0 clinician (this association may be conducted at the central system servicing unit 108a); and, 

associating the first clinician with that clinician's digital assistant 118. The server 109 uses the 
information gained in its precondition check at block 1515 to establish a relationship between 
the medical device 120 (and in one embodiment the specific channel 121 of the infusion pump 
120) the patient, the primary or first clinician and the first clinician's digital assistant 118. It is 

2 5 understood that there is a many to many relationship between patients 112 and clinicians 116. 

Accordingly, numerous first clinicians, numerous second clinicians, and numerous n-level 
clinicians may be associated with a specific patient. Further, n-level escalations are also 
possible within this system. 

Typically, the server 108a has stored therein the patient to clinician many-to-many 

30 associations, and the patient to unit associations. The server 108a transmits these associations to 

server 109, and the server 109 stores these associations. Similarly, the server 108a sends the 
charge clinician to unit associations to the server 109 for storage. 
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Following the precondition check at block 1515, the server 109 determines the 
appropriate channel 121 to patient 112 to clinician 116 mapping. Once the mapping is complete, 
the server 109 determines if the first clinician's digital assistant 118 is active at block 1520. If 
the first clinician's digital assistant 118 is active, then the server 109 generates a signal 
5 representative of the alarm or alert condition that exist. The signal includes data such as the 

patient's name, patient's location, room identification, bed identification, alarm or alert type, 
condition description, time, date, clinician identification and/or prescription. In the preferred 
embodiment, the signal is transmitted from the server 109 to the wireless access point 114. The 
wireless access point 114 then transmits the signal relating to the alarm or alert condition via a 

10 wireless communication transmission to the clinician's digital assistant 1 18 at block 1525. 

The signal relating to the alarm or alert condition may also be transmitted at block 1525 
to a charge clinician, a secondary first clinician, or a secondary clinician. Such a signal may be 
transmitted via a wireless or wired communication. Further, the charge clinician may be 
utilizing a digital assistant 118, a desktop computer, or some other electronic device. The 

15 charge clinician is generally a supervisor or some person to whom the clinicians report. 

Additionally, the charge clinician may be a person who assists in workflow for the clinicians, or 
who assists in monitoring alarm or alert conditions. 

The signal is received by the clinician's digital assistant 118, and subsequently displayed 
at block 1530 in FIGURE 15. This block provides for indicating the alarm or alert condition on 

20 the clinician's digital assistant 118. The indication on the clinician's digital assistant may be 

visual, audible, or both visual and audible. Further, the visual indication may include one or 
more of text, icons, symbols, etc. Similarly, as explained above, the audible indication may 
include a variety of audible tones at a variety of decibel levels. The visual and audible 
indicators are configurable by the hospital. FIGURE 16A discloses an exemplar screen shot of 

2 5 an alarm/alert interface list screen 1662a on the clinician's digital assistant 1 18. The alarm/alert 

list interface 1662a contains a list of patients that are currently associated to active channel 
alarm/alerts. As shown in FIGURE 16A, this clinician's digital assistant 118 currently has three 
active alarm/alert indications. There is an alarm condition for patient one 1664, an alarm 
condition for patient two 1666, and an alert condition for patient three 1668. Each patient name 

3 0 and corresponding alarm/alert icon is a hyperlink to the appropriate pump alarm details interface 

screen, as shown in FIGURE 17. In one embodiment, the list of patients is filtered to only 
include the patients that are currently associated to the clinician 116 logged into the digital 
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assistant 118 displaying this interface screen. This clinician-to-patient association can be as a 
primary clinician or as a temporary coverage clinician. A secondary clinician can also be 
accessed through the escalation process. The alarm/alert list interface 1662 is typically accessed 
by clicking on an alarm/alert icon 4872 displayed on the clinician's 116 digital assistant 118 
5 during normal clinician workflow. 

As explained above, when the alarm or alert condition is indicated on the clinician's 
digital assistant at block 1530, this indication may be provided visually, audibly or both. When 
an audible indication is provided at the clinician's digital assistant 118, the alarm icon 4872 
appears on the display 118a of the clinician's digital assistant 118. If an audible indication is 

10 provided, the clinician may have the ability to mute the audible indication even though the 

clinician has not responded to the alarm or alert condition. If the clinician does silence the 
alarm, the server 109 will initiate a silence timer. The visual indication will remain even though 
the audible indication has been muted. As shown in FIGURE 16A, if an alarm/alert would be 
providing an audible indication at the clinician's digital assistant 118 but for the muting by the 

15 clinician, a muted alarm/alert icon 4874 is provided. Further, upon escalation of the alarm/alert 

condition, if the clinician does not respond to the alarm within the timer limit, the muting of the 
audible indication may be disengaged. An alternate embodiment of the audible indication may 
be a vibration alert. 

Further, it is understood that multiple alarm/alert conditions may occur simultaneously 
20 or in overlapping periods. Accordingly, simultaneous or overlapping signals containing data 

relating to the specific alarm or alert condition are generated and sent at block 1510 from the 
medical device 120, to the server 109. The alarm/alert signals may originate from the same or 
different medical devices 120. Further, the alarm/alert signals may relate to the same or 
different patients. Each of the alarm/alert signals, however, are individually routed in the 
2 5 alarm/alert escalation process 1500 as herein described for an individual alarm/alert condition. 

As shown in FIGURE 16A, a specific clinician may have numerous alarm/alert indications on 
his/her digital assistant 118. Another example of an alarm/alert screen is shown on interface 
screen 1662b of FIGURE 16B. As is typical in the present system, the line referenced as 1676 
in interface screen 1662b of FIGURE 16B indicates the end of a list, and specifically the 
30 alarm/alert indication list for a specific clinician in this interface. 

FIGURE 17 illustrates a detailed patient alarm/alert interface 1765 after the clinician has 
selected to view one of the alarm/alert indications for the patient hyperlink on the clinician's 
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digital assistant 118 from the interface list 1662a of FIGURE 16A. Here, the clinician has 
selected the alarm indication for patient one 1664. The alarm/alert detail screen 1765 provides 
the clinician with a message detailing the reason for the alarm/alert. The clinician can click on 
the refresh button 4819 to update the current information displayed on the screen 1765. As 
5 shown on interface 1867 of FIGURE 18, multiple alarms or alerts 1878, 1882 may exist for the 

same patient. This alarm/alert interface 1867 provides a list of all active pump alarm/alerts that 
are currently associated to a given patient. These active pump alarm/alerts can be from multiple 
channels 121 and/or pumps 120, and even spread across multiple hubs 107. This interface 
screen 1867 is accessed by specifying a given patient on the pump alarm list screen 1662. 

10 After the signal is sent to the clinician's digital assistant at block 1525, and received by 

the primary clinician's digital assistant 118 at block 1530, a timer is initiated at block 1535 at 
the server 109. The timer has a timer limit. A typical escalation timer limit is approximately 2 
minutes; however, this limit is configurable by the hospital. At block 1540, the system 
determines if a response is provided to the alert or alarm within the timer limit. If the timer limit 

15 is reached without acknowledgment from the primary clinician's digital assistant 118, the 

process proceeds to block 1545. At block 1545, the system makes the further inquiry as to 
whether an acknowledgment or response to the alarm/alert condition has been made at the 
medical device 120. If no response has been made at either the primary clinician's digital 
assistant 118, the medical device 120, or by the charge clinician, then at block 1545 the 

2 o alarm/alert process is escalated. 

If at any time a loss of communication occurs after an alarm/alert condition is triggered, 
but prior to the acknowledgment of the alarm/alert condition, the alarm/alert condition will 
reassert once the loss of communication has been fixed. Similarly, if an alarm/alert condition is 
triggered after a loss of communication, the alarm/alert condition will reassert once the 

2 5 communication has been re-established. 

When an alarm is escalated, the server 109 conducts another precondition check at block 
1550. This precondition check 1550 may include: associating the patient with a secondary 
clinician (this association may be conducted at the central system servicing unit 108a); and, 
associating the second clinician with that clinician's digital assistant 118, also referred to as the 

30 second clinician's device or second clinician's digital assistant 118. The server 109 uses the 

information gained in its precondition check at block 1550 to establish a relationship between 
the medical device 120, the patient, the secondary clinician and the second clinician's digital 
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assistant 118. 

Following the second precondition check at block 1550, the server 109 may also 
determine if the second clinician's digital assistant 118 is active. If the second clinician's digital 
assistant 118 is active, then the server 109 generates an escalated signal representative of the 
5 alarm or alert condition that exists. The escalated signal similarly includes data such as the 

patient's name, patient's location, room identification, bed identification, alarm or alert type, 
condition description, time, date, clinician identification and/or prescription. In the preferred 
embodiment, the escalated signal is transmitted from the server 109 to the wireless access point 
114. The wireless access point 114 then transmits the escalated signal relating to the alarm or 

10 alert condition via a wireless communication transmission to the second clinician's digital 

assistant 1 18 at block 1555. 

The escalated signal relating to the alarm or alert condition may also be transmitted at 
block 1555 to a charge clinician. Such an escalated signal may be via a wireless or wired 
communication. Further, the charge clinician may be utilizing a digital assistant, a desktop 

15 computer, or some other electronic device. As explained above, the charge clinician is generally 

a supervisor or some person to whom the clinicians report, or a person who assists in workflow 
for the clinicians, or who assists in monitoring alarm or alert conditions. 

The escalated signal is received by the second clinician's digital assistant 118, and 
subsequently displayed at block 1560 in FIGURE 15. This block provides for indicating the 

20 alarm or alert condition on the second clinician's digital assistant 118. The indication on the 

second clinician's device may be visual, audible, or both visual and audible. Further, the visual 
indication may include one or more of text, icons, symbols, etc. Similarly, as explained above, 
the audible indication may include a variety of audible tones. It is understood, however, that the 
original signal, see block 1525, sent to the first clinician is still maintained at the first clinician's 

25 digital assistant, as shown in block 1530 of FIGURE 15. The signal at the first clinician's digital 

assistant 118 may be elevated (i.e., it may be shown in a larger size or font, it may be flashing, 
the volume of the audible alert may be louder, etc.). 

After the secondary signal is sent to the clinician's digital assistant at block 1555 and 
received by the secondary clinician's digital assistant 118 at block 1560, there are at least two 

30 individuals (the first clinician and/or the charge clinician) and at least two devices that have the 

alarm/alert conditions active. Accordingly, any of these clinicians may respond to the 
alarm/alert condition as shown in blocks 1540 and 1565. The escalated alarm process will 
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continue, at block 1570, until the alarm/alert condition is cleared either at one of the clinician's 
digital assistant 118, the charge clinician's computer or device, or at the medical device 120. 

Referring back to block 1520, if the server 109 determines that the primary clinician's 
digital assistant 118 is not active, and if at block 1545 the server 109 determines that the 
alarm/alert condition still exists, the server 109 will proceed to block 1550 as discussed above to 
determine the appropriate secondary or charge clinician to send the alarm/alert signal. 
Additionally, it is understood that block 1520 may occur at any time during the alarm/alert 
escalation process 1500. One reason for a clinician's digital assistant 118 being inactive could 
be a loss of a signal from the server 109. As shown in the communication loss interface screen 
4501 of FIGURES 45 A and 45B, when the signal is lost the digital assistant 118 will provide the 
clinician 116 with a screen 4501, and/or an audible/vibratory indication, indicating a lost signal. 
The communication loss screen 4501 also informs the clinician 116 as to which patients the 
signal has been lost. At screen 4501 the system 210 also provides the clinician 1 16 with trouble 
shooting tips to regain a signal. When a hub 107 or digital assistant 118 is outside of the 
wireless range, pump alarms and alerts cannot be received at the digital assistant 1 18. 

Other reasons for the digital assistant 118 being inactive could be the loss of battery 
power at the digital assistant 118, a loss of battery power at the wireless hub 107, or the digital 
assistant losing a signal with the access point 114. The system 210 does provide the clinician 
116 with a low battery screen. As shown in interface screen 4603 of FIGURE 46, one type of 
low battery screen is a screen to alert the clinician that a low battery situation exists on a 
wireless hub 107 connected to a patient's infusion pump. When a low battery screen is 
provided, the screen contains a list of patients for which infusions are associated with that 
specific hub 107. The list of patients is generally filtered to include only the patients that are 
currently associated to the clinician logged into the digital assistant 118 displaying the screen 
4603, and also all patients that share the same infusion pump 120/hub 107 with the logged-in 
clinician. This clinician-to-patient association can be as a first clinician or as a secondary 
clinician through the escalation process. It is understood that other reasons for the clinician's 
digital assistant 118 being inactive are possible. Nevertheless, if at any time the clinician's 
digital assistant 118 becomes inactive, the process 1500 may proceed to block 1550 such that 
the signal may be sent to a secondary clinician and/or to the charge clinician. Further, as 
explained above with respect to a time-out feature and other features of this disclosure, if a 
communication signal is lost from either the server 109 or the medical device 120, a signal lost 
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message may be provided on the digital assistant 1 18 as shown in FIGURES 45 A and 45B. 

At any time during the alarm/alert process, the primary clinician may respond to the 
alarm/alert signal. If the primary clinician responded to the alarm/alert signal at block 1540, the 
escalated process will be avoided. If, however, an escalated process has been initiated at block 
1550, either the primary physician or the secondary clinician may respond to the alarm/alert 
signal at block 1565. Similarly, the alarm/alert condition may be resolved at the medical device 
120, or by the charge clinician at any time, either before or during an alarm/alert escalation 
process. After the alarm/alert condition has been resolved, either at block 1540, block 1565, at 
the medical device 120 or by the charge clinician, the audible alarm at the medical device 120 
and at the clinician's digital assistant 118 will be terminated at block 1540. 

The server 109 records all alarm/alert conditions as an event at block 1585. Recording 
the event may include: recording information on the alarm/alert condition; recording the 
clinician who responded to the alarm/alert condition; recording the initial time of the alarm/alert 
condition (see block 1505); and, recording the time when the alarm/alert condition was rectified. 
Additionally, at block 1590, the server 109 will reset the timer and update a medical device 
alarm list. The alarm/alert condition may also be recorded in the pump's event history. 
Example Use Cases 

FIGURE 55A - FIGURE 62 are flowcharts of example operations that may be 
performed using the system described herein. Example operations include administering a new 
infusion, scanning a pump channel, changing the channel a pump is assigned to, 
stopping/discontinuing an infusion, resuming an infusion, and removing a pump. In general, 
each of these operations receives inputs from an electronic device, such as a digital assistant 
118, which includes information indicating the operation to be performed, information 
identifying which patient 112 is to be affected (e.g., patient ID), and information identifying 
which medication 124 for that patient 112 is to be affected (e.g., Rx ID). This information is 
then sent to the first central server 109, which confirms that channel identification information 
matches the infusion order information and confirms that the correct infusion operation 
occurred. 

Administer Infusion Process 

FIGURE 55A illustrates an example of an administer infusion process 5500. Portions of 
the administer infusion process 5500 are an alternate embodiment of the comparison procedure 
5200 outlined above. The administer infusion process 5500 may be used to start a new infusion. 
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In general, the administer infusion process 5500 receives inputs from an electronic device, such 
as a digital assistant 118, which includes information indicating an administer infusion process 
is to be performed, information identifying which patient 1 12 is to be affected (e.g., patient ID), 
and information identifying which medication 124 for that patient 112 is to be started (e.g., Rx 
5 ID). The process 5500 then sends this information to the first central server 109, which 

confirms that channel identification information matches the infusion order information and 
confirms that the correct infusion is started. 

More specifically, the example administer infusion process 5500 begins when the second 
central server 108a causes the digital assistant 1 18 to display a list of patients at block 5502. An 

10 example of a digital assistant display 118a showing a list of patients is illustrated in FIGURE 

24. The list of patients is preferably limited to patients associated with the user (e.g., a clinician 
116) who is logged into that digital assistant 118 at the time. Once the user selects a patient 
112, information identifying the selection and/or the patient 112 is transmitted from the digital 
assistant 118 back to the second central server 108a. Communication between the digital 

15 assistant 118 and the second central server 108a may be via any suitable communication channel 

such as the wireless/wired network 102 described above. The second central server 108a then 
causes the digital assistant 1 18 to display a list of actions at block 5504. An example of a digital 
assistant display 1 18a showing a list of actions is illustrated in FIGURE 25. The list of actions 
is preferably limited to actions associated with the selected patient 112. For example, an 

2 0 "administer infusion" action would only be available if at least one infusion was currently 

associated with the selected patient 112. 

When the user selects the "administer infusion" action from the list of actions, 
information identifying the action selected is sent to the second central server 108a. In 
response, the second central server 108a causes the digital assistant 118 to display a screen 

25 prompting the user to select a medication 124 to be infused from a list of medications displayed 

on the digital assistant 118 at block 5506. An example of a digital assistant display 118a 
showing a list of medications is illustrated in FIGURE 26. The list of medications is preferably 
retrieved from the second central server 108a database based on actual orders for this patient 
1 12. Of course, the list may have any number of items including no infusions to administer or 

30 one infusion to administer. Data indicative of the selected medication 124 is then sent to the 

second central server 108a. 

Next, the second central server 108a causes the digital assistant 118 to display a screen 
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prompting the user to scan a machine-readable identifier associated with the patient 1 12 at block 
5508. An example of a digital assistant display 118a prompting the user to scan a machine- 
readable identifier associated with the patient 112 is illustrated in FIGURE 36. The user may 
use the scanner of the digital assistant 118 to scan a barcode label on the patient's wristband 
5 112a. Alternatively, the user may manually enter the patient identifier into the digital assistant 

118. The patient identifier is then sent to the second central server 108a for verification at block 
5510. The second central server 108a then attempts to lookup the patient identifier in a 
database. If the patient identifier (e.g., wristband ID) does not exist as a valid patient identifier 
in the database, the second central server 108a causes the digital assistant 118 to display an 
10 invalid patient notification at block 5512. Once the user acknowledges the invalid patient 

notification (or the notification times out), the digital assistant 118 re-displays the screen 
prompting the user to scan a machine-readable identifier associated with the patient 1 12 at block 
5508. 

If the patient identifier (e.g., wristband ID) does exist as a valid patient identifier in the 
15 database at block 5510, the second central server 108a causes the digital assistant 118 to display 

a screen prompting the user to scan a machine-readable identifier associated with the medication 
124 to be administered at block 5514. An example of a digital assistant display 1 18a prompting 
the user to scan a machine-readable identifier associated with the medication 124 is illustrated in 
FIGURE 34. The user may use the scanner of the digital assistant 118 to scan the medication 

2 0 label 124a on a bag of medication 124 (e.g., a barcode on an infusion bag). Alternatively, the 

user may manually enter the medication identifier into the digital assistant 118. The medication 
identifier is then sent to the second central server 108a for verification at block 5516. The 
second central server 108a attempts to lookup the medication identifier in the database. If the 
medication identifier (e.g., bag ID) does not exist as a valid medication identifier in the 
25 database, the second central server 108a causes the digital assistant 118 to display an invalid 

item notification at block 5518. Once the user acknowledges the invalid item notification (or 
the notification times out), the digital assistant 118 re-displays the screen prompting the user to 
scan a machine-readable identifier associated with the medication 124 to be resumed at block 
5514. 

3 0 Once a valid medication identifier is obtained, the second central server 108a uses the 

medication identifier to look up a patient identifier in the database. The patient identifier from 
the database is then compared to the scanned (or manually entered) patient identifier to 
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determine if the scanned (or manually entered) medication 124 belongs to the scanned (or 
manually entered) patient 112 at block 5520. If the two patient identifiers do not match, the 
second central server 108a causes the digital assistant 1 18 to display the invalid item notification 
at block 5518. 

5 If the two patient identifiers do match (i.e., this patient 112 goes with this medication 

124), the second central server 108a causes the digital assistant 118 to display a screen 
prompting the user to enter a route, a line, and a site at block 5522. An example of a digital 
assistant display 118a prompting the user to enter a route, a line, and a site is illustrated in 
FIGURE 37. Data indicative of the route, line, and site is then sent to the second central server 

10 108a for verification at block 5524. If a route mismatch occurs, the second central server 108a 

causes the digital assistant 118 to display a route mismatch notification at block 5526. An 
example of a digital assistant display 1 18a with a mismatch notification is illustrated in FIGURE 
40. Once the user acknowledges the route mismatch notification (or the notification times out), 
the digital assistant 118 re-displays the screen prompting the user to enter a route, a line, and a 

15 site at block 5522. If a route mismatch does not occur, the second central server 108a causes the 

digital assistant 1 18 to display a screen asking the user to select between a manual prescription 
comparison and an automatic prescription comparison at block 5528. If a manual prescription 
comparison is selected at block 5530, the second central server 108a causes the digital assistant 
1 18 to display an indication of the parameters to be manually verified by the user at block 5532. 
* 20 Subsequently, the second central server 108a determines if there are more items (e.g., 

medications) to administer for this patient 112 at block 5534. For example, the infusion order 
selected in block 5506 may require a primary infusion and a piggyback infusion. If there are 
more items (e.g., medications) to administer for this patient 112, the second central server 108a 
causes the digital assistant 118 to display the screen prompting the user to scan a machine- 

2 5 readable identifier associated with the medication 124 to be administered at block 5514. An 

example of a digital assistant display 118a prompting the user to scan a machine-readable 
identifier associated with the medication 124 is illustrated in FIGURE 34. If there are no more 
items (e.g., medications) to administer for this patient 1 12, the second central server 108a causes 
the digital assistant 1 18 to display a screen showing the administration results at block 5536. An 

30 example of a digital assistant display 118a showing the administration results is illustrated in 

FIGURE 57. 

The administration results are also passed to the first central server 109. For example, 
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the administration results may be passed to the first central server 109 as form variables (as if 
submitted from a web page). The first central server 109 then checks all of the administration 
results for any failures at block 5538. If there are no failures, the first central server 109 
commits all of the new channel-patient-medication relationships to the first central server 109 
5 database at block 5540. The first central server 109 then returns control to the second central 

server 108a by navigating to a predefined URL associated with the second central server 108a at 
block 5542. If there are one or more failures, the first central server 109 discards channel- 
patient-medication relationships associated with the failures and commits channel-patient- 
medication relationships associated with the successes to the first central server 109 database at 

10 block 5544. The failures may be associated with the second central server 108a and/or the first 

central server 109. Accordingly, the first central server 109 preferably communicates failures 
associated with the first central server 109 (e.g., an integrity failure) back to the second central 
server 108a when the first central server 109 returns control to the second central server 108a by 
navigating to a predefined URL associated with the second central server 108a at block 5546. 

15 Returning to block 5530, if an automatic prescription comparison is selected, the second 

central server 108a transmits a "prescription comparison" XML document to the first central 
server 109 at block 5531. The "prescription comparison" XML document includes the patient 
identifier (e.g., wristband ED), the medication identifier (e.g., bag ID), a completion URL, and a 
cancellation URL. The completion URL is a network address used if a prescription match is 

20 found. The cancellation URL is a network address used if a prescription match is not found. 

Once the first central server 109 receives the "prescription comparison" XML document, 
the first central server 109 determines if the "prescription comparison" XML document is valid 
at block 5548. For example, the first central server 109 may check if any data normally 
expected in a "prescription comparison" XML document is missing from the received 

25 "prescription comparison" XML document. If the first central server 109 determines that the 

"prescription comparison" XML document is not valid, the first central server 109 causes the 
digital assistant 118 to display an error message indicating to the user that the "prescription 
comparison" action could not be executed at block 5550. This display may include a reason 
such as which data was missing from the "prescription comparison" XML document. After the 

30 user presses an "OK" button to acknowledge the error message, the first central server 109 

returns a cancellation code to the second central server 108a via the cancellation URL at block 
5552. 
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If the first central server 109 determines that the "prescription comparison" XML 
document is valid, the first central server 109 initiates a channel scanning process 5554. 
Generally, the channel scanning process 5554 prompts the user to scan a machine-readable 
identifier associated with the "new" pump channel (e.g., pump channel 103a) and determines if 
5 the scanned channel is available (e.g., not assigned to any patient 112; assigned to the current 

patient 1 12, but not in use; assigned to another patient 1 12 and overwritten; etc.). If the scanned 
channel is not available, the "administer infusion" action is cancelled. In such an event, the first 
central server 109 returns a cancel code to the second central server 108a via the cancellation 
URL. If the scanned channel is available, a new channel-patient-medication relationship is 
10 created. The channel scanning process 5554 is described in more detail below with reference to 

FIGURE 56. 

If the channel scanning process 5554 determines that the scanned channel is valid and 
available, the first central server 109 causes the digital assistant 118 to display a screen 
prompting the user to program the pump channel at block 5556. Preferably, the digital assistant 

15 display 118a includes a "Compare" button and a "Cancel" button. If the user presses the 

"Cancel" button, the first central server 109 discards the new channel-patient-medication 
relationship at block 5558 and returns the cancellation code to the second central server 108a via 
the cancellation URL at block 5552. If the user presses the "Compare" button, the first central 
server 109 determines if communication with the pump channel is operating properly at block 

2 0 5560. For example, the first central server 109 may determine that communication with the 

pump channel is not operating properly if status information has not been received from the 
channel within a predefined time period. 

If communication with the pump channel is not operating properly, the first central 
server 109 causes the digital assistant 118 to display a screen indicating that a prescription 

2 5 comparison cannot be performed due to a loss of communication with the pump channel at 

block 5562. Again, the digital assistant display 118a preferably includes a "Compare" button 
and a "Cancel" button. If the user presses the "Cancel" button, the first central server 109 
discards the new channel-patient-medication relationship at block 5558 and returns the 
cancellation code to the second central server 108a via the cancellation URL at block 5552. If 

3 0 the user presses the "Compare" button, the first central server 109 rechecks if communication 

with the pump channel is operating properly at block 5560. 

If communication with the pump channel is operating properly, the first central server 
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109 determines if any data associated with this channel is missing at block 5564. For example, 
the first central server 109 may determine that data associated with this channel is missing if 
status information received from the channel is missing an expected sequence number. If 
channel data is missing, the first central server 109 causes the digital assistant 118 to display a 
5 screen indicating that a prescription comparison cannot be performed due to missing channel 

data at block 5564. Again, the digital assistant display 118a preferably includes a "Compare" 
button and a "Cancer' button. If the user presses the "Cancel'* button, the first central server 
109 discards the new channel-patient-medication relationship at block 5558 and returns the 
cancellation code to the second central server 108a via the cancellation URL at block 5552. If 

10 the user presses the "Compare" button, the first central server 109 rec hecks if communication 

with the pump channel is operating properly at block 5560. 

If no channel data is missing, the first central server 109 determines if the channel is 
already running at block 5568. For example, the first central server 109 may determine if the 
pump channel is running by reading status information received from the channel. If the 

15 channel is already running, the first central server 109 causes the digital assistant 118 to display 

a screen indicating that a prescription comparison cannot be performed because the channel is 
already running at block 5570. An example of a digital assistant display 118a indicating that a 
prescription comparison cannot be performed is illustrated in FIGURE 42. The digital assistant 
display 118a may also indicate that the user should press a certain key on the pump 120 (e.g., 

2 0 start). Again, the digital assistant display 118a preferably includes a "Compare" button and a 

"Cancel" button. If the user presses the "Cancel" button, the first central server 109 discards the 
new channel-patient-medication relationship at block 5558 and returns the cancellation code to 
the second central server 108a via the cancellation URL at block 5552. If the user presses the 
"Compare" button, the first central server 109 rechecks if communication with the pump 

25 channel is operating properly at block 5572. 

If communication with the pump channel is not operating properly, the first central 
server 109 causes the digital assistant 118 to display a screen indicating that a prescription 
comparison cannot be performed due to a loss of communication with the pump channel at 
block 5574. Again, the digital assistant display 118a preferably includes a "Compare" button 

30 and a "Cancel" button. If the user presses the "Cancel" button, the first central server 109 

discards the new channel-patient-medication relationship at block 5558 and returns the 
cancellation code to the second central server 108a via the cancellation URL at block 5552. If 
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the user presses the "Compare" button, the first central server 109 rechecks if communication 
with the pump channel is operating properly at block 5574. If communication with the pump 
channel is operating properly, the first central server 109 performs the requested prescription 
comparison at block 5576. 

Returning to block 5568, if . the channel is not running, the first central server 109 
determines if the pump channel is setup to send rate information at block 5578. If the pump 
channel is not setup to send rate information, the first central server 109 causes the digital 
assistant 118 to display a screen indicating that a prescription comparison cannot be performed 
because the channel is not sending rate information at block 5580. An example of a digital 
assistant display 118a indicating that a prescription comparison cannot be performed is 
illustrated in FIGURE 41. The digital assistant display 118a may also indicate that the user 
should press a certain key on the pump 120 (e.g., rate). Again, the digital assistant display 1 18a 
preferably includes a "Compare" button and a "Cancel" button. If the user presses the "Cancel" 
button, the first central server 109 discards the new channel-patient-medication relationship at 
block 5558 and returns the cancellation code to the second central server 108a via the 
cancellation URL at block 5552. If the user presses the "Compare" button, the first central 
server 109 rechecks if communication with the pump channel is operating properly at block 
5572. If the pump channel is setup to send rate information, the first central server 109 
performs the requested prescription comparison at block 5576. 

As part of the prescription comparison, the first central server 109 uses the channel 
identifier obtained by the channel scanning process 5554 and the patient identifier transmitted 
by the second central server 108a to look up a medication identifier in the database (or two 
medication identifiers if a primary medication 124 and a piggyback medication 124 are both 
associated with this channel). The medication identifier(s) from the database are then compared 
to the scanned (or manually entered) medication identifier at block 5582. If one of the 
medication identifier(s) from the database does not match the scanned (or manually entered) 
medication identifier, the first central server 109 causes the digital assistant 118 to display an 
invalid medication notification at block 5584. For example, the digital assistant 118 may 
display a message that the scanned medication 124 is not associated with the scanned channel 
and indicate the actual medication 124 assigned to the scanned channel (both primary and 
piggyback if applicable). Again, the digital assistant display 118a preferably includes a 
"Compare" button and a "Cancel" button. If the user presses the "Cancel" button, the first 
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central server 109 discards the new channel-patient-medication relationship at block 5558 and 
returns the cancellation code to the second central server 108a via the cancellation URL at block 
5552. If the user presses the "Compare" button, the first central server 109 rechecks if 
communication with the pump channel is operating properly at block 5572. 
5 As an additional part of the prescription comparison, the first central server 109 uses the 

channel identifier obtained by the channel scanning process 5554 and the patient identifier 
transmitted by the second central server 108a to look up a medication rate in the database. The 
medication rate from the database is then compared to the actual rate received from the pump 
channel at block 5584. If medication rate from the database does not match the actual rate 

10 received from the pump channel, the first central server 109 causes the digital assistant 118 to 

display a rate mismatch notification at block 5586. An example of a digital assistant display 
118a with a mismatch notification is illustrated in FIGURE 40. For example, the digital 
assistant 118 may display a message that the rate of the channel should be adjusted and indicate 
the correct value. Again, the digital assistant display 118a preferably includes a "Compare" 

15 button and a "Cancel" button. If the user presses the "Cancel" button, the first central server 

109 discards the new channel-patient-medication relationship at block 5558 and returns the 
cancellation code to the second central server 108a via the cancellation URL at block 5552. If 
the user presses the "Compare" button, the first central server 109 rechecks if communication 
with the pump channel is operating properly at block 5572. 

20 In addition, the digital assistant display 1 18a may include an "Accept Mismatch" button. 

If the user presses the "Accept Mismatch" button, the first central server 109 returns a mismatch 
code and the mismatching rates to the second central server 108a via the completion URL at 
block 5588. If medication rate from the database does match the actual rate received from the 
pump channel at block 5584, the first central server 109 causes the digital assistant 118 to 

2 5 display a match notification at block 5590. An example of a digital assistant display 1 18a with a 

match notification is illustrated in FIGURE 39. Once the user accepts the match notification 
message, the first central server 109 returns a match code and the matching rate to the second 
central server 108a via the completion URL at block 5588. 
Channel Scanning Process (for administer infusion process) 

30 FIGURE 56 illustrates an example of the channel scanning process 5554 used above 

with reference to FIGURE 55. Generally, the channel scanning process 5554 prompts the user 
to scan a machine-readable identifier associated with a pump channel and determines if the 
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scanned channel is available (e.g., assigned to the current patient 112, but not in use). If the 
scanned channel is not available, the "administer infusion" action is cancelled. In such an event, 
the first central server 109 returns a cancel code to the second central server 108a via the 
cancellation URL. If the scanned channel is available, a new channel-patient-medication 
5 relationship is created. 

More specifically, the example channel scanning process 5554 begins when the first 
central server 109 causes the digital assistant 1 18 to display a screen prompting the user to select 
a subchannel (e.g., primary or piggyback) and scan a machine-readable identifier associated 
with the channel at block 5602. An example of a digital assistant display 1 18a prompting the 

10 user to scan a machine-readable identifier associated with the channel is illustrated in FIGURE 

38. For example, the user may use the scanner of the digital assistant 118 to scan a barcode 
label associated with the channel. Alternatively, the user may manually enter the channel 
identifier into the digital assistant 118. In addition, the user may choose to skip the scanning 
process which causes a return to the second central server 108a via the completion URL or he 

15 may choose to cancel the scan which causes a return to the second central server 108a via the 

cancellation URL. 

The channel identifier is then sent to the first central server 109 for verification at block 
5604. The first central server 109 then attempts to lookup the channel identifier in the database. 
If the channel identifier does not exist as a valid channel identifier in the database (e.g., not 
20 properly formatted, not configured in the first central server 109, etc.), the first central server 

109 causes the digital assistant 1 18 to display an invalid channel notification at block 5606. For 
example, the digital assistant 118 may display a message that the channel is not configured in 
the first central server 109 and include buttons allowing the user to rescan the channel identifier 
or cancel out of the operation. If the user chooses to cancel the operation, the first central server 

2 5 109 preferably sends a cancel code to the second central server 108a via the cancellation URL at 

block 5608. 

Once a valid channel identifier is obtained, the first central server 109 uses the channel 
identifier to look up a patient identifier in the database. The first central server 109 then 
compares the patient identifier from the database to the scanned (or manually entered) patient 

3 0 identifier at block 5610. If a valid patient identifier is present in the database, but the two 

patient identifiers do not match (i.e., the channel is assigned to a different patient 112), the first 
central server 109 checks the database to see if the channel is running (in either primary and/or 
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piggyback mode) at block 5612. 

If the channel is running, the first central server 109 causes the digital assistant 118 to 
display a "cannot overwrite" error message indicating that a different patient 112 is associated 
with the scanned channel and that the channel is currently running at block 5614. The error 
5 message may also include data indicative of the patient 112 that is associated with the scanned 

channel (e.g., patient's name), the primary medication 124, and/or the piggyback medication 
124. Preferably, the user is given the option to cancel or rescan. If the user chooses to cancel 
the operation, the first central server 109 sends a cancel code to the second central server 108a 
via the cancellation URL at block 5608. If the user chooses to rescan, the first central server 

10 109 causes the digital assistant 118 to display the screen prompting the user to select a 

subchannel (e.g., primary or piggyback) and scan a machine-readable identifier associated with 
the channel at block 5602. 

If the channel is not running, the first central server 109 causes the digital assistant 118 
to display a "continue overwrite" warning message indicating that a different patient 112 is 

15 associated with the scanned channel, but the channel is not currently running at block 5616. 

Preferably, the warning message indicates that continuing will overwrite existing data (e.g., 
remove the association with the other patient 1 12). The warning message may also include data 
indicative of the patient 112 that is associated with the scanned channel (e.g., patient's name), 
the primary medication 124, and/or the piggyback medication 124. Preferably, the user is given 

20 the option to cancel, rescan, or continue. If the user chooses to cancel the operation, the first 

central server 109 sends a cancel code to the second central server 108a via the cancellation 
URL at block 5608. If the user chooses to rescan, the first central server 109 causes the digital 
assistant 118 to display the screen prompting the user to select a subchannel (e.g., primary or 
piggyback) and scan a machine-readable identifier associated with the channel at block 5602. 

2 5 An example of a digital assistant display 118a prompting the user to scan a machine-readable 

identifier associated with the channel is illustrated in FIGURE 38. If the user chooses to 
continue, the first central server 109 creates a new channel-patient-medication relationship and 
stores the new channel-patient-medication relationship in the current "web session" at block 
5618. If this new channel-patient-medication relationship is ultimately kept, the first central 

30 server 109 commits the new channel-patient-medication relationship to the first central server 

109 database block 5540 of FIGURE 55 as described in detail above. 

If a valid patient identifier is present in the database, and the two patient identifiers do 
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match (i.e., the channel is assigned to this patient 1 12) at block 5620, the first central server 109 
checks the database to see if the subchannel is empty at block 5622. In other words, the first 
central server 109 checks that there is no primary infusion associated with this channel if the 
primary subchannel was selected in block 5602 and checks that there is no piggyback infusion 
5 associated with this channel if the piggyback subchannel was selected in block 5602. If the 

subchannel is empty, the first central server 109 creates a new channel-patient-medication 
relationship and stores the new channel-patient-medication relationship in the current "web 
session" at block 5618. If the subchannel is not empty, the first central server 109 checks the 
database to see if the subchannel is running (in either primary and/or piggyback mode) at block 
10 5624. 

If the subchannel is running, the first central server 109 causes the digital assistant 1 18 to 
display a "cannot overwrite" error message indicating that this patient 112 is already associated 
with the scanned channel and that the selected subchannel is currently running at block 5626. 
The error message may also include data indicative of the patient 1 12 (e.g., patient's name), the 

15 primary medication 124, and/or the piggyback medication 124. Preferably, the user is given the 

option to cancel or rescan. If the user chooses to cancel the operation, the first central server 
109 sends a cancel code to the second central server 108a via the cancellation URL at block 
5608. If the user chooses to rescan, the first central server 109 causes the digital assistant 1 18 to 
display the screen prompting the user to select a subchannel (e.g., primary or piggyback) and 

2 0 scan a machine-readable identifier associated with the channel at block 5602. 

If the subchannel is not running, the first central server 109 causes the digital assistant 
118 to display a "continue" message indicating that this patient 112 is associated with the 
scanned channel, but the selected subchannel is not currently running at block 5628. The 
message may also include data indicative of the patient 112 (e.g., patient's name), the primary 

2 5 medication 124, and/or the piggyback medication 124. Preferably, the user is given the option 

to cancel, rescan, or continue. If the user chooses to cancel the operation, the first central server 
109 sends a cancel code to the second central server 108a via the cancellation URL at block 
5608. If the user chooses to rescan, the first central server 109 causes the digital assistant 1 18 to 
display the screen prompting the user to select a subchannel (e.g., primary or piggyback) and 

3 0 scan a machine-readable identifier associated with the channel at block 5602. If the user 

chooses to continue, the first central server 109 creates a new channel-patient-medication 
relationship and stores the new channel-patient-medication relationship in the current "web 
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session" at block 5618. When the user presses continue again, the first central server 109 
returns control to the current action (e.g., administer infusion). 
Change Pump Channel Process 

FIGURE 57A illustrates an example of a change pump channel process 5700. The 
5 change pump channel process 5700 may be used (e.g., by a nurse) to change an infusion from 

one pump channel to another pump channel without losing the channel-patient-medication 
relationship in the database. In general, the change pump channel process 5700 receives inputs " 
from an electronic device, such as a digital assistant 118, which includes information indicating 
a change pump channel process is to be performed, information identifying which patient 1 12 is 

10 to be affected (e.g., patient ID), and information identifying which medication 124 for that 

patient 1 12 is to be affected (e.g., Rx ID). The process 5700 then sends this information to the 
first central server 109, which confirms that channel identification information matches the 
change pump channel order information. 

More specifically, the example change pump channel process 5700 begins when the 

15 second central server 108a causes the digital assistant 118 to display a list of patients for 

selection at block 5702. An example of a digital assistant display 1 18a showing a list of patients 
is illustrated in FIGURE 24. The list of patients is preferably limited to patients associated with 
the user (e.g., a clinician 116) who is logged into that digital assistant 118 at the time. Once the 
user selects a patient 112, information identifying the selection and/or the patient 112 is 

20 transmitted from the digital assistant 118 back to the second central server 108a. 

Communication between the digital assistant 118 and the second central server 108a may be via 
any suitable communication channel such as the wireless/wired network 102 described above. 
The second central server 108a then causes the digital assistant 118 to display a list of actions at 
block 5704. An example of a digital assistant display 118a showing a list of actions is 

2 5 illustrated in FIGURE 25. The list of actions is preferably limited to actions associated with the 

selected patient 112. For example, a "change pump channel" action would only be available if 
an infusion associated with this patient 112 was currently listed in the second central server 
108a database. 

When the user selects the "change pump channel" action from the list of actions, 
30 information identifying the action selected is sent to the second central server 108a. In 

response, the second central server 108a causes the digital assistant 118 to display a screen 
prompting the user to scan a machine-readable identifier associated with the medication 124 to 
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be affected by this "change pump channel" action at block 5706. An example of a digital 
assistant display 118a prompting the user to scan a machine-readable identifier associated with 
the medication 124 is illustrated in FIGURE 34. The user may use the scanner of the digital 
assistant 118 to scan the medication label 124a on a bag of medication 124 (e.g., a barcode on 
5 an infusion bag). Alternatively, the user may manually enter the medication identifier into the 

digital assistant 118. 

The medication identifier is then sent to the second central server 108a for verification at 
block 5708. The second central server 108a attempts to lookup the medication identifier in the 
database. If the medication identifier (e.g., bag ID) does not exist as a valid medication 

10 identifier in the database, the second central server 108a causes the digital assistant 118 to 

display an invalid item notification at block 5710. Once the user acknowledges the invalid item 
notification (or the notification times out), the digital assistant 118 re-displays the screen 
prompting the user to scan a machine-readable identifier associated with the medication 124 to 
be affected by this "change pump channel" action at block 5706. 

15 If the medication identifier (e.g., bag ID) does exist as a valid medication identifier in the 

database at block 5708, the second central server 108a transmits a "change pump channel" XML 
document to the first central server 109. The "change pump channel" XML document includes 
the patient identifier (e.g., selected from list in block 5702, the medication identifier (e.g., bag 
ID), a completion URL, and a cancellation URL. The completion URL is a network address 

2 0 used if the "change pump channel" action is attempted. The cancellation URL is a network 

address used if the "change pump channel" action fails. 

Once the first central server 109 receives the "change pump channel" XML document, 
the first central server 109 determines if the "change pump channel" XML document is valid at 
block 5724. For example, the first central server 109 may check if any data normally expected 

2 5 in a "change pump channel" XML document is missing from the received "change pump 

channel" XML document. If the first central server 109 determines that the "change pump 
channel" XML document is not valid, the first central server 109 causes the digital assistant 118 
to display an error message indicating to the user that the "change pump channel" action could 
not be executed at block 5726. This display may include a reason such as which data was 

30 missing from the "change pump channel" XML document. After the user presses an "OK" 

button to acknowledge the error message, the first central server 109 returns a failure code to the 
second central server 108a via the cancellation URL at block 5728. 
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If the first central server 109 determines that the "change pump channel" XML 
document is valid, the first central server 109 initiates a channel scanning process 5730. This 
channel scanning process 5730 is associated with the "old" channel (i.e., the user is attempting 
to move from and "old" channel to a "new" channel). Generally, the channel scanning process 
5 5730 prompts the user to scan a machine-readable identifier associated with the "old" pump 

channel and determines if the scanned channel is associated with the patient identifier and the 
medication identifier (as described in more detail below with reference to FIGURE 58. If the 
scanned channel is not associated with the patient identifier and the medication identifier, the 
"change pump channel" action is cancelled. In such an event, the first central server 109 returns 

10 a cancel code to the second central server 108a via the cancellation URL at block 5728. 

If the scanned channel is associated with the patient identifier and the medication 
identifier (i.e., the old channel is valid), the first central server 109 causes the digital assistant 
1 18 to display a message indicating the patient 1 12, the old channel of the primary infusion, and 
the old channel of the piggyback infusion at block 5732. Preferably, the digital assistant 118 

15 also displays a message indicating that both infusions (primary and piggyback) are moved by 

this operation, along with a "Continue" button and a "Cancel" button. If the user presses the 
"Cancel" button, the first central server 109 returns a cancel code to the second central server 
108a via the cancellation URL at block 5728. 

If the user presses the "Continue" button, the first central server 109 initiates another 

20 channel scanning process 5734. This channel scanning process 5734 is associated with the 

"new" channel (i.e., the user is attempting to move from an "old" channel to a "new" channel). 
Generally, the channel scanning process 5734 prompts the user to scan a machine-readable 
identifier associated with the "new" pump channel and determines if the scanned channel is 
available (e.g., not assigned to any patient 112; assigned to the current patient 112, but not in 

25 use; assigned to another patient 112 and overwritten; etc.). If the scanned channel is not 

available, the "change pump channel" action is cancelled. In such an event, the first central 
server 109 returns a cancel code to the second central server 108a via the cancellation URL at 
block 5728. The channel scanning process 5734 is described in more detail below with 
reference to FIGURE 59. 

30 If the scanned channel is associated with the patient identifier and the medication 

identifier (i.e., the new channel is valid), the first central server 109 determines if any other 
infusions are currently associated with the new channel at block 5736. If another infusion is 
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already associated with the new channel, the first central server 109 causes the digital assistant 
118 to display a message indicating that another infusion is currently associated with the new 
channel and a message asking the user if he/she would like to overwrite the current infusion at 
block 5738. Preferably, this message includes a "Yes" button, a "No" button, and a "Cancel" 
5 button. If the user presses the "Cancel" button, the first central server 109 returns a cancel code 

to the second central server 108a via the cancellation URL at block 5728. If the user presses the 
"No" button, the first central server 109 initiates another channel scanning process 5834. 

If the user presses the "No" button, the first central server 109 attempts to remove the 
channel-patient-medication relationship in the database for the new channel at block 5740. If 

10 the attempt to remove the channel -patient-medication relationship in the database for the new 

channel is unsuccessful at block 5742, the first central server 109 causes the digital assistant 118 
to display a "change pump channel" error message including the patient identifier, the 
medication identifier associated with the primary infusion that was not moved (if applicable), 
and the medication identifier associated with the piggyback infusion that was not moved (if 

15 applicable) at block 5744. Once the user acknowledges the "change pump channel" error 

message by pressing an "OK" button, the first central server 109 returns a failure code to the 
second central server 108a via the completion URL at block 5746. 

If another infusion is not already associated with the new channel at block 5736, or the 
attempt to remove the channel-patient-medication relationship in the database for the new 

2 0 channel is successful at block 5742, the first central server 109 attempts to change the channel- 

patient-medication relationship in the database for both the primary and piggyback infusions 
from the old channel to the new channel at block 5748. If the attempt to move the channel- 
patient-medication relationship in the database from the old channel to the new channel is not 
successful at block 5750, the first central server 109 causes the digital assistant 118 to display 

2 5 the "change pump channel" error message. 

If the attempt to move the channel-patient-medication relationship in the database from 
the old channel to the new channel is successful at block 5750, the first central server 109 causes 
the digital assistant 118 to display a "change pump channel" success message including the 
patient identifier, the medication identifier associated with the primary infusion that was moved 

30 (if applicable), and the medication identifier associated with the piggyback infusion that was 

moved (if applicable) at block 5752. Preferably, the display also includes a message to the user 
to move the tubing to the new channel. Once the user acknowledges the "change pump 
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channel" success message by pressing, an "OK" button, the first central server 109 returns a 
success code to the second central server 108a via the completion URL at block 5746. 
Channel Scanning Process 

FIGURE 58 illustrates an example of the channel scanning process 5730 used above 
5 with reference to FIGURE 57. Generally, the channel scanning process 5730 prompts the user 

to scan a machine-readable identifier associated with a pump channel and determines if the 
scanned channel is associated with the previously scanned patient identifier and medication 
identifier. If the scanned channel is not associated with the patient identifier and the medication 
identifier, the current action (e.g., stop, discontinue, resume, channel change, remove pump, 

10 etc.) is cancelled. 

More specifically, the example channel scanning process 5730 begins when the first 
central server 109 causes the digital assistant 1 18 to display a screen prompting the user to scan 
a machine-readable identifier associated with the channel at block 5802. An example of a 
digital assistant display 1 18a prompting the user to scan a machine-readable identifier associated 

15 with the channel is illustrated in FIGURE 38. For example, the user may use the scanner of the 

digital assistant 118 to scan a barcode label associated with the channel. Alternatively, the user 
may manually enter the channel identifier into the digital assistant 118. 

The channel identifier is then sent to the first central server 109 for verification at block 
5804. The first central server 109 then attempts to look up the channel identifier in the database. 

2 0 If the channel identifier does not exist as a valid channel identifier in the database (e.g., not 

properly formatted, not configured in the first central server 109, etc.), the first central server 
109 causes the digital assistant 1 18 to display an invalid channel notification at block 5806. For 
example, the digital assistant 118 may display a message that the channel is not configured in 
the first central server 109 and include buttons allowing the user to rescan the channel identifier 

2 5 or cancel out of the operation. If the user chooses to cancel the operation, the first central server 

109 preferably sends a cancel code to the second central server 108a via the cancellation URL at 
block 5808. 

Once a valid channel identifier is obtained, the first central server 109 uses the channel 
identifier to look up a patient identifier in the database. The patient identifier from the database 

3 0 is then compared to the scanned (or manually entered) patient identifier at block 5810. If the 

two patient identifiers do not match, the first central server 109 causes the digital assistant 118 
to display an invalid patient notification at block 5812. For example, the digital assistant 118 
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may display a message that the scanned patient 112 is not associated with the scanned channel 
and indicate the actual patient 112 assigned to the scanned channel. Again, the PDA display 
may include buttons allowing the user to rescan the channel identifier or cancel out of the 
operation. If the user chooses to cancel the operation, the first central server 109 preferably 
sends a cancel code to the second central server 108a via the cancellation URL at block 5808. 

Once a valid channel-patient relationship is established, the first central server 109 uses 
the channel identifier and the patient identifier to look up a medication identifier in the database 
(or two medication identifiers if a primary medication 124 and a piggyback medication 124 are 
both associated with this channel). The medication identifier(s) from the database are then 
compared to the scanned (or manually entered) medication identifier at block 5814. If one of 
the medication identifier(s) from the database does not match the scanned (or manually entered) 
medication identifier, the first central server 109 causes the digital assistant 118 to display an 
invalid medication notification at block 5816. For example, the digital assistant 118 may 
display a message that the scanned medication 124 is not associated with the scanned channel 
and indicate the actual medication 124 assigned to the scanned channel (both primary and 
piggyback if applicable). Again, the PDA display may include buttons allowing the user to 
rescan the channel identifier or cancel out of the operation. If the user chooses to cancel the 
operation, the first central server 109 preferably sends a cancel code to the second central server 
108a via the cancellation URL at block 5808. 

If a valid channel-patient-medication relationship is established, the first central server 
109 indicates a valid channel scan occurred and returns control to the current action (e.g., 
administer, stop, discontinue, resume, channel change, remove pump, etc.) without issuing 
additional displays to the digital assistant 118 at block 5818. 
Channel Scanning Process (new channel) 

FIGURE 59 illustrates an example of the channel scanning process 5734 used above 
with reference to FIGURE 57. Generally, the channel scanning process 5734 prompts the user 
to scan a machine-readable identifier associated with a pump channel and determines if the 
scanned channel is available (e.g., assigned to the current patient 112, but not in use). If the 
scanned channel is not available, the current action (e.g., channel change) is cancelled. 

More specifically, the example channel scanning process 5734 begins when the first 
central server 109 causes the digital assistant 1 18 to display a screen prompting the user to scan 
a machine-readable identifier associated with the channel at block 5902. An example of a 
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digital assistant display 1 18a prompting the user to scan a machine-readable identifier associated 
with the channel is illustrated in FIGURE 38. For example, the user may use the scanner of the 
digital assistant 1 18 to scan a barcode label associated with the channel. Alternatively, the user 
may manually enter the channel identifier into the digital assistant 1 18. 
5 The channel identifier is then sent to the first central server 109 for verification at block 

5904. The first central server 109 then attempts to lookup the channel identifier in the database. 
If the channel identifier does not exist as a valid channel identifier in the database (e.g., not 
properly formatted, not configured in the first central server 109, etc.), the first central server 
109 causes the digital assistant 1 18 to display an invalid channel notification at block 5906. For 
10 example, the digital assistant 118 may display a message that the channel is not configured in 

the first central server 109 and include buttons allowing the user to rescan the channel identifier 
or cancel out of the operation. If the user chooses to cancel the operation, the first central server 
109 preferably sends a cancel code to the second central server 108a via the cancellation URL at 
block 5908. 

15 Once a valid channel identifier is obtained, the first central server 109 uses the channel 

identifier to look up a patient identifier in the database. The first central server 109 then 
compares the patient identifier from the database to the scanned (or manually entered) patient 
identifier at block 5910. If a valid patient identifier is present in the database, but the two 
patient identifiers do not match (i.e., the channel is assigned to a different patient 1 12), the first 

2 0 central server 109 checks the database to see if the channel is running (in either primary and/or 

piggyback mode) at block 5912. 

If the channel is running, the first central server 109 causes the digital assistant 118 to 
display a "cannot overwrite" error message indicating that a different patient 112 is associated 
with the scanned channel and that the channel is currently running at block 5914. The error 

2 5 message may also include data indicative of the patient 112 that is associated with the scanned 

channel (e.g., patient's name), the primary medication 124, and/or the piggyback medication 
124. Preferably, the user is given the option to cancel or rescan. If the user chooses to cancel 
the operation, the first central server 109 sends a cancel code to the second central server 108a 
via the cancellation URL at block 5908. If the user chooses to rescan, the first central server 

30 109 causes the digital assistant 1 18 to display the screen prompting the user to scan a machine- 

readable identifier associated with the channel at block 5902. 

If the channel is not running, the first central server 109 causes the digital assistant 118 
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to display a "continue overwrite" warning message indicating that a different patient 112 is 
associated with the scanned channel, but the channel is not currently running at block 5916. 
Preferably, the warning message indicates that continuing will overwrite existing data (e.g., 
remove the association with the other patient 1 12). The warning message may also include data 
5 indicative of the patient 112 that is associated with the scanned channel (e.g., patient's name), 

the primary medication 124, and/or the piggyback medication 124. Preferably, the user is given 
the option to cancel, rescan, or continue. If the user chooses to cancel the operation, the first 
central server 109 sends a cancel code to the second central server 108a via the cancellation 
URL at block 5908. If the user chooses to rescan, the first central server 109 causes the digital 

10 assistant 118 to display the screen prompting the user to scan a machine-readable identifier 

associated with the channel at block 5902. If the user chooses to continue, the first central 
server 109 causes the digital assistant 118 to display a message indicting that it is okay to use 
the selected channel at block 5918. When the user presses "continue" the first central server 
109 returns control to the current action (e.g., administer, channel change, etc.) without issuing 

15 additional displays to the digital assistant 118. 

If a valid patient identifier is present in the database, and the two patient identifiers do 
match (i.e., the channel is assigned to this patient 1 12) at block 5920, the first central server 109 
checks the database to see if the channel is empty (e.g., no primary or piggyback infusion 
associated with this channel) at block 5922. If the channel is empty, the first central server 109 

20 causes the digital assistant 118 to display the message indicating that it is okay to use the 

selected channel at block 5918. If the channel is not empty, the first central server 109 checks 
the database to see if the channel is running (in either primary and/or piggyback mode) at block 
5924. 

If the channel is running, the first central server 109 causes the digital assistant 118 to 
2 5 display a "cannot overwrite" error message indicating that this patient 112 is already associated 

with the scanned channel and that the channel is currently running at block 5926. The error 
message may also include data indicative of the patient 112 (e.g., patient's name), the primary 
medication 124, and/or the piggyback medication 124. Preferably, the user is given the option 
to cancel or rescan. If the user chooses to cancel the operation, the first central server 109 sends 
30 a cancel code to the second central server 108a via the cancellation URL at block 5908. If the 

user chooses to rescan, the first central server 109 causes the digital assistant 118 to display the 
screen prompting the user to scan a machine-readable identifier associated with the channel at 



Attorney Docket No. 



(1417GP1047) 



121 

block 5902. 

If the channel is not running, the first central server 109 causes the digital assistant 118 
to display a "continue" message indicating that this patient 112 is associated with the scanned 
channel, but the channel is not currently running at block 5928. The message may also include 
5 data indicative of the patient 112 (e.g., patient's name), the primary medication 124, and/or the 

piggyback medication 124. Preferably, the user is given the option to cancel, rescan, or 
continue. If the user chooses to cancel the operation, the first central server 109 sends a cancel 
code to the second central server 108a via the cancellation URL at block 5908. If the user 
chooses to rescan, the first central server 109 causes the digital assistant 118 to display the 

10 screen prompting the user to scan a machine-readable identifier associated with the channel at 

block 5902. If the user chooses to continue, the first central server 109 causes the digital 
assistant 118 to display a message indicting that it is okay to use the selected channel at block 
5918. When the user presses continue again, the first central server 109 returns control to the 
current action (e.g., channel change) without issuing additional displays to the digital assistant 

15 118. 

Stop/Discontinue Infusion Process 

FIGURE 60 illustrates an example of a stop/discontinue infusion process 6000. The 
stop/discontinue infusion process 6000 may be used to temporarily stop (i.e., pause) an infusion 
process or completely discontinue (i.e., end) an infusion process. In general, the 

20 stop/discontinue infusion process 6000 receives inputs from an electronic device, such as a 

digital assistant 118, which includes information regarding whether a stop or a discontinue is to 
be performed, information identifying which patient 112 is to be affected (e.g., patient ID), and 
information identifying which medication 124 for that patient 112 is to be stopped or 
discontinued (e.g., Rx ID). The process 6000 then sends this information to the first central 

2 5 server 109, which confirms that channel identification information matches the stop/discontinue 

order information and confirms that the correct infusion is stopped or discontinued. 

More specifically, the example stop/discontinue infusion process 6000 begins when the 
second central server 108a causes the digital assistant 118 to display a list of patients at block 
6002. An example of a digital assistant display 1 18a showing a list of patients is illustrated in 

3 0 FIGURE 24. The list of patients is preferably limited to patients associated with the user (e.g., a 

clinician 116) who is logged into that digital assistant 118 at the time. Once the user selects a 
patient 112, information identifying the selection and/or the patient 112 is transmitted from the 
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digital assistant 118 back to the second central server 108a. Communication between the digital 
assistant 118 and the second central server 108a may be via any suitable communication channel 
such as the wireless/wired network 102 described above. The second central server 108a then 
causes the digital assistant 1 18 to display a list of actions at block 6004. An example of a digital 
5 assistant display 1 18a showing a list of actions is illustrated in FIGURE 25. The list of actions 

is preferably limited to actions associated with the selected patient 112. For example, a "stop 
infusion" action and a "discontinue infusion" action would only be available if an infusion 
associated with this patient 112 was currently in a running state. 

When the user selects the "stop infusion" action or the "discontinue infusion" action 

10 from the list of actions, information identifying the action selected is sent to the second central 

server 108a. In response, the second central server 108a causes the digital assistant 118 to 
display a screen listing all running infusions for that patient 112 and prompting the user to scan 
a machine-readable identifier associated with the medication 124 to be stopped or discontinued 
at block 6006. An example of a digital assistant display 118a prompting the user to scan a 

15 machine-readable identifier associated with the medication 124 is illustrated in FIGURE 34. 

The user may use the scanner of the digital assistant 1 18 to scan the medication label 124a on a 
bag of medication 124 (e.g., a barcode on an infusion bag). Alternatively, the user may 
manually enter the medication identifier into the digital assistant 118. 

The medication identifier is then sent to the second central server 108a for verification at 

2 0 block 6008. The second central server 108a attempts to lookup the medication identifier in the 

database. If the medication identifier (e.g., bag ID) does not exist as a valid medication 
identifier in the database, the second central server 108a causes the digital assistant 118 to 
display an invalid item notification at block 6010. Once the user acknowledges the invalid item 
notification (or the notification times out), the digital assistant 118 re-displays the screen 

25 prompting the user to scan a machine-readable identifier associated with the medication 124 to 

be stopped or discontinued at block 6006. 

If the medication identifier (e.g., bag ID) does exist as a valid medication identifier in the 
database at block 6008, the second central server 108a causes the digital assistant 118 to display 
a screen prompting the user to scan a machine-readable identifier associated with the patient 112 

30 at block 6012. An example of a digital assistant display 118a prompting the user to scan a 

machine-readable identifier associated with the patient 112 is illustrated in FIGURE 36. The 
user may use the scanner of the digital assistant 118 to scan a barcode label on a patient 
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wristband 1 12a. Alternatively, the user may manually enter the patient identifier into the digital 
assistant 118. The patient identifier is then sent to the second central server 108a for 
verification at block 6014. The second central server 108a then attempts to lookup the patient 
identifier in the database. If the patient identifier (e.g., wristband ID) does not exist as a valid 
5 patient identifier in the database, the second central server 108a causes the digital assistant 118 

to display an invalid patient notification at block 6016. Once the user acknowledges the invalid 
patient notification (or the notification times out), the digital assistant 118 re-displays the screen 
prompting the user to scan a machine-readable identifier associated with the patient 1 12 at block 
6012. 

10 If the patient identifier (e.g., wristband ID) does exist as a valid patient identifier in the 

database at block 6014, the second central server 108a may also prompt the user for a code 
indicative of the reason for the "stop infusion" action or the "discontinue infusion" action. If 
this reason code is not supplied, the system preferably displays a message to the user that a 
reason code must be supplied. In addition, the second central server 108a may timestamp the 

15 order and/or prompt the user for a time when the action is to occur. Still further, the second 

central server 108a preferably checks the status of the infusion order to determine if the infusion 
order is active or discontinued. 

If the infusion order is active, the second central server 108a determines if the user is 
attempting to issue a "stop infusion" action or a "discontinue infusion" action based on the user 

20 selection from block 6004 at block 6018. If the user is attempting to issue a "stop infusion" 

action, the second central server 108a sets a "DCFlag" in a "stop infusion" XML document to 
"FALSE" at block 6020. If the user is attempting to issue a "discontinue infusion" action, the 
second central server 108a sets the "DCFlag" in the "stop infusion" XML document to "TRUE" 
at block 6022. Of course, any well-known method of indicating the state of a variable may be 

2 5 used. 

The "stop infusion" XML document, including the patient identifier (e.g., wristband ID), 
the medication identifier (e.g., bag ID), a completion URL, a cancellation URL, and the DCFlag 
(indicating stop vs. discontinue) are then transmitted to the first central server 109. The 
completion URL is a network address used if the infusion is successfully stopped or 
30 discontinued. The cancellation URL is a network address used if the "stop infusion" action or 

the "discontinue infusion" action fails or is cancelled. 

Once the first central server 109 receives the "stop infusion" XML document, the first 
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central server 109 determines if the "stop infusion" XML document is valid at block 6024. For 
example, the first central server 109 may check if any data normally expected in a "stop 
infusion" XML document is missing from the received "stop infusion" XML document. If the 
first central server 109 determines that the "stop infusion" XML document is not valid, the first 
5 central server 109 causes the digital assistant 118 to display an error message indicating to the 

user that the "stop infusion" action or the "discontinue infusion" action could not be executed at 
block 6026. This display may include a reason such as which data was missing from the "stop 
infusion" XML document. After the user presses an "OK" button to acknowledge the error 
message, the first central server 109 returns a failure code to the second central server 108a via 

10 the cancellation URL at block 6028. 

If the first central server 109 determines that the "stop infusion" XML document is valid, 
the first central server 109 initiates a channel scanning process 5730. Generally, the channel 
scanning process 5730 prompts the user to scan a machine-readable identifier associated with 
the pump channel currently running the infusion to be stopped or discontinued and determines if 

15 the scanned channel is associated with the patient identifier and the medication identifier (as 

described in detail above with reference to FIGURE 58. If the scanned channel is not associated 
with the patient identifier and the medication identifier, the "stop infusion" action or the 
"discontinue infusion" action is cancelled. In such an event, the first central server 109 returns a 
cancel code to the second central server 108a via the cancellation URL at block 6028. 

20 If the scanned channel is associated with the patient identifier and the medication 

identifier (i.e., the channel is valid), the first central server 109 causes the digital assistant 1 18 to 
display a message indicating the patient 112 and infusion to be stopped including the details of 
the medication 124 to be stopped and the channel the medication 124 is on at block 6032. 
Preferably, the PDA display also includes a "Continue" button and a "Cancel" button. In this 

2 5 manner, the user may manually stop the indicated infusion and then press the "Continue" button 

to inform the first central server 109 to check if the correct infusion was actually stopped or 
discontinued. Alternatively, the user may press the "Cancel" button, at which point the first 
central server 109 returns a cancel code to the second central server 108a via the cancellation 
URL at block 6028. 

30 If the user presses the "Continue" button, the first central server 109 determines if the 

infusion was stopped by reading status information sent to the first central server 109 by the 
pump 120 at block 6034. If the pump 120 is unable to communicate with the first central server 
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109, the first central server 109 generates a loss of communication event for that channel. If 
communication with a channel is lost, the status of the infusion on that channel cannot be 
changed to "stopped" or "discontinued" until communication with that channel is restored. If 
communication is working properly, but the infusion was not stopped, the first central server 
5 109 causes the digital assistant 118 to display a warning message indicating that the infusion 

was not stopped and indicating the patient 112 and infusion to be stopped at block 6036. 
Preferably, the display also includes an "OK" button and a "Cancel" button. If the user presses 
the "OK" button, the first central server 109 checks again to see if the correct infusion was 
actually stopped or discontinued at block 6034. If the user presses the "Cancel" button, the first 
10 central server 109 returns a cancel code to the second central server 108a via the cancellation 

URL at block 6028. 

If the infusion is stopped at block 6034, the first central server 109 checks if this is a 
"stop infusion" action or a "discontinue infusion" action at block 6038. For example, the first 
central server 109 may check the state of a flag such as the DCFlag set by block 6020 or block 
15 6022. If this is a "stop infusion" action (i.e., pause infusion), the first central server 109 returns 

a success code and DCFlag=FALSE to the second central server 108a via the completion URL 
at block 6044. 

If instead this is a "discontinue infusion" action (i.e., end infusion), the first central 
server 109 preferably attempts to remove the database association between the patient identifier, 

20 the medication identifier, and the channel identifier for either the primary infusion or the 

piggyback infusion, but preferably not both at block 6040. If the user wants to stop or 
discontinue both a primary infusion and a piggyback infusion running on a channel, the user 
may execute the "stop infusion" action or the "discontinue infusion" action twice, once for each 
infusion. If the first central server 109 is not successful in removing the database association at 

2 5 block 6042, the first central server 109 returns a failure code to the second central server 108a 

via the cancellation URL at block 6028. If the first central server 109 is successful in removing 
the database association at block 6042, the first central server 109 returns a success code and 
DCFlag=TRUE to the second central server 108a via the completion URL at block 6044. 

The first central server 109 removes the association between the patient identifier, the 

30 medication identifier, and the channel identifier for the selected infusion only if a "discontinue 

infusion" action is successful. Otherwise, the association is maintained. For example, if a "stop 
infusion" action is successful or a "discontinue infusion" action fails, the association between 
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the patient identifier, the medication identifier, and the channel identifier is maintained. 
Similarly, the second central server 108a only updates the status of the infusion to "stopped" or 
"discontinued" upon receiving a success code from the first central server 109. Any other result 
(e.g., cancel code or failure code) causes the second central server 108a to keep the infusion in 
its previous state. Preferably, at any point in the process 6000 the user has the option to cancel 
out of the process 6000. The Stop/Discontinue process may be utilized to document that the 
infusion was restarted for purposes of the MAR. 
Resume Infusion Process 

FIGURE 61 illustrates an example of a resume infusion process 6100. The resume 
infusion process 6100 may be used to restart a stopped (i.e., paused) infusion process. However, 
the resume infusion process 6100 may not be used to restart a discontinued (i.e., ended) infusion 
process. In general, the resume infusion process 6100 receives inputs from an electronic device, 
such as a digital assistant 118, which includes information indicating a resume process is to be 
performed, information identifying which patient 112 is to be affected (e.g., patient ID), and 
information identifying which medication 124 for that patient 112 is to be resumed (e.g., Rx 
ID). The process 6100 then sends this information to the first central server 109, which 
confirms that channel identification information matches the resume order information and 
confirms that the correct infusion is resumed. 

More specifically, the example resume infusion process 6100 begins when the second 
central server 108a causes the digital assistant 118 to display a list of patients at block 6102. An 
example of a digital assistant display 118a showing a list of patients is illustrated in FIGURE 
24. The list of patients is preferably limited to patients associated with the user (e.g., a clinician 
116) who is logged into that digital assistant 118 at the time. Once the user selects a patient 
112, information identifying the selection and/or the patient 112 is transmitted from the digital 
assistant 118 back to the second central server 108a. Communication between the digital 
assistant 118 and the second central server 108a may be via any suitable communication channel 
such as the wireless/wired network 102 described above. The second central server 108a then 
causes the digital assistant 1 18 to display a list of actions at block 6104. An example of a digital 
assistant display 118a showing a list of actions is illustrated in FIGURE 25. The list of actions 
is preferably limited to actions associated with the selected patient 1 12. For example, a "resume 
infusion" action would only be available if an infusion associated with this patient 112 was 
currently in a stopped state. 
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When the user selects the "resume infusion" action from the list of actions, information 
identifying the action selected is sent to the second central server 108a. In response, the second 
central server 108a causes the digital assistant 1 18 to display a screen prompting the user to scan 
a machine-readable identifier associated with the medication 124 to be resumed at block 6106. 
5 An example of a digital assistant display 118a prompting the user to scan a machine-readable 

identifier associated with the medication 124 is illustrated in FIGURE 34. The user may use the 
scanner of the digital assistant 118 to scan the medication label 124a on a bag of medication 124 
(e.g., a barcode on an infusion bag). Alternatively, the user may manually enter the medication 
identifier into the digital assistant 118. 

10 The medication identifier is then sent to the second central server 108a for verification at 

block 6108. The second central server 108a attempts to lookup the medication identifier in the 
database. If the medication identifier (e.g., bag ID) does not exist as a valid medication 
identifier in the database, the second central server 108a causes the digital assistant 118 to 
display an invalid item notification at block 61 10. Once the user acknowledges the invalid item 

15 notification (or the notification times out), the digital assistant 118 re-displays the screen 

prompting the user to scan a machine-readable identifier associated with the medication 124 to 
be resumed at block 6106. If the user scans a machine-readable identifier associated with a 
medication 124 to be resumed, but the medication 124 has been discontinued, the second central 
server 108a preferably causes the digital assistant 1 18 to display a message to the user indicating 

2 0 that the medication 124 cannot be resumed due to its discontinued state. 

If the medication identifier (e.g., bag ID) does exist as a valid medication identifier in the 
database at block 6108, and has not been discontinued, the second central server 108a causes the 
digital assistant 1 18 to display a screen prompting the user to scan a machine-readable identifier 
associated with the patient 112 at block 6112. An example of a digital assistant display 118a 

2 5 prompting the user to scan a machine-readable identifier associated with the patient 112 is 

illustrated in FIGURE 36. The user may use the scanner of the digital assistant 118 to scan a 
barcode label on a patient wristband 112a. Alternatively, the user may manually enter the 
patient identifier into the digital assistant 118. The patient identifier is then sent to the second 
central server 108a for verification at block 6114. The second central server 108a then attempts 

3 0 to lookup the patient identifier in the database. If the patient identifier (e.g., wristband ID) does 

not exist as a valid patient identifier in the database, the second central server 108a causes the 
digital assistant 118 to display an invalid patient notification at block 6116. Once the user 
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acknowledges the invalid patient notification (or the notification times out), the digital assistant 
118 re-displays the screen prompting the user to scan a machine-readable identifier associated 
with the patient 1 12 at block 6112. 

If the patient identifier (e.g., wristband ID) does exist as a valid patient identifier in the 
5 database at block 6114, the second central server 108a may also prompt the user for a code 

indicative of the reason for the "resume infusion" action. If this reason code is not supplied, the 
system preferably displays a message to the user that a reason code must be supplied. In 
addition, the second central server 108a may timestamp the order and/or prompt the user for a 
time when the action is to occur. Still further, the second central server 108a preferably checks 

10 the status of the infusion order to determine if the infusion order is active or discontinued. 

If the infusion order is active, the second central server 108a transmits a "resume 
infusion" XML document to the first central server 109. The "resume infusion" XML document 
includes the patient identifier (e.g., wristband ID), the medication identifier (e.g., bag ID), a 
completion URL, and a cancellation URL. The completion URL is a network address used if 

15 the infusion is successfully resumed. The cancellation URL is a network address used if the 

"resume infusion" action fails or is cancelled. 

Once the first central server 109 receives the "resume infusion" XML document, the first 
central server 109 determines if the "resume infusion" XML document is valid at block 6124. 
For example, the first central server 109 may check if any data normally expected in a "resume 

2 0 infusion" XML document is missing from the received "resume infusion" XML document. If 

the first central server 109 determines that the "resume infusion" XML document is not valid, 
the first central server 109 causes the digital assistant 1 18 to display an error message indicating 
to the user that the "resume infusion" action could not be executed at block 6126. This display 
may include a reason such as which data was missing from the "resume infusion" XML 

2 5 document. After the user presses an "OK" button to acknowledge the error message, the first 

central server 109 returns a failure code to the second central server 108a via the cancellation 
URL at block 6128. 

If the first central server 109 determines that the "resume infusion" XML document is 
valid, the first central server 109 initiates the channel scanning process 5730. Generally, the 
30 channel scanning process 5730 prompts the user to scan a machine-readable identifier associated 

with the pump channel currently associated with the infusion to be resumed and determines if 
the scanned channel is associated with the patient identifier and the medication identifier (as 
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described in detail above with reference to FIGURE 58). If the scanned channel is not 
associated with the patient identifier and the medication identifier, the "resume infusion" action 
is cancelled. In such an event, the first central server 109 returns a cancel code to the second 
central server 108a via the cancellation URL at block 6128. 
5 If the scanned channel is associated with the patient identifier and the medication 

identifier (i.e., the channel is valid), the first central server 109 causes the digital assistant 1 18 to 
display a message indicating the patient 112 and infusion to be resumed at block 6132. 
Preferably, the PDA display also includes a "Continue" button and a "Cancel" button. In this 
manner, the user may manually resume the indicated infusion and then press the "Continue" 
10 button to inform the first central server 109 to check if the correct infusion was actually 

resumed. Alternatively, the user may press the "Cancel" button, at which point the first central 
server 109 returns a cancel code to the second central server 108a via the cancellation URL at 
block 6128. 

If the user presses the "Continue" button, the first central server 109 determines if the 
15 infusion was resumed by reading status information sent to the first central server 109 by the 

pump 120 at block 6134. If the pump 120 is unable to communicate with the first central server 
109, the first central server 109 generates a loss of communication event for that channel. If 
communication with a channel is lost, the status of the infusion on that channel cannot be 
changed to "resumed" until communication with that channel is restored. If communication is 
2 0 working properly, but the infusion was not resumed, the first central server 109 causes the 

digital assistant 118 to display a warning message indicating that the infusion was not resumed 
and indicating the patient 112 and infusion to be resumed at block 6136. Preferably, the display 
also includes an "OK" button and a "Cancel" button. If the user presses the "OK" button, the 
first central server 109 checks again to see if the correct infusion was actually resumed at block 

2 5 6134. If the user presses the "Cancel" button, the first central server 109 returns a cancel code 

to the second central server 108a via the cancellation URL at block 6128. 

If the infusion is resumed at block 6134, the first central server 109 returns a success 
code to the second central server 108a via the completion URL at block 6144. The first central 
server 109 maintains the association between the patient identifier, the medication identifier, and 

3 0 the channel identifier for the selected infusion. The second central server 108a only updates the 

status of the infusion to "running" upon receiving a success code from the first central server 
109. Any other result (e.g., cancel code or failure code) causes the second central server 108a to 
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keep the infusion in its previous state. Preferably, if the user wants to resume both a primary 
infusion and a piggyback infusion running on a channel, the user may execute the "resume 
infusion" action twice, once for each infusion. The Resume process may be utilized t document 
that the infusion was restarted for purposes of the MAR. 
5 Remove Pump Process 

FIGURE 62 illustrates an example of a remove pump process 6200. The remove pump 
process 6200 may be used to terminate a channel-patient-medication relationship in the first 
central server 109 database independent of a discontinue infusion order existing in the pharmacy 
database and without going through the stop/discontinue infusion process 6000 describe above. 

10 In general, the remove pump process 6200 receives inputs from an electronic device, such as a 

digital assistant 118, which includes information indicating a remove pump process is to be 
performed, information identifying which patient 112 is to be affected (e.g., patient ID), and 
information identifying which medication 124 for that patient 1 12 is to be affected (e.g., Rx ID). 
The process 6200 then sends this information to the first central server 109, which confirms that 

15 channel identification information matches the remove pump order information and confirms 

that the correct pump 120 is removed. 

More specifically, the example remove pump process 6200 begins when the second 
central server 108a causes the digital assistant 118 to display a list of patients for selection at 
block 6202. An example of a digital assistant display 118a showing a list of patients is 

2 0 illustrated in FIGURE 24. The list of patients is preferably limited to patients associated with 

the user (e.g., a clinician 1 16) who is logged into that digital assistant 118 at the time. Once the 
user selects a patient 112, information identifying the selection and/or the patient 112 is 
transmitted from the digital assistant 118 back to the second central server 108a. 
Communication between the digital assistant 1 18 and the second central server 108a may be via 

2 5 any suitable communication channel such as the wireless/wired network 102 described above. 

The second central server 108a then causes the digital assistant 1 18 to display a list of actions at 
block 6204. An example of a digital assistant display 118a showing a list of actions is 
illustrated in FIGURE 25. The list of actions is preferably limited to actions associated with the 
selected patient 112. For example, a "remove pump" action would only be available if an 

30 infusion associated with this patient 112 was currently listed in the first central server 109 

database. 

When the user selects the "remove pump" action from the list of actions, information 
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identifying the action selected is sent to the second central server 108a. In response, the second 
central server 108a causes the digital assistant 1 18 to display a screen prompting the user to scan 
a machine-readable identifier associated with the medication 124 to be affected by this "remove 
pump" action at block 6206. An example of a digital assistant display 1 18a prompting the user 
5 to scan a machine-readable identifier associated with the medication 124 is illustrated in 

FIGURE 34. The user may use the scanner of the digital assistant 118 to scan the medication 
label 124a on a bag of medication 124 (e.g., a barcode on an infusion bag). Alternatively, the 
user may manually enter the medication identifier into the digital assistant 118. 

The medication identifier is then sent to the second central server 108a for verification at 

10 block 6208. The second central server 108a (or the digital assistant 118) checks if a properly 

formatted medication identifier was received. Preferably, the second central server 108a does 
not need to check if the medication identifier matches a current infusion in the second central 
server 108a database, because the purpose of the "remove pump" action is to remove 
associations from the first central server 109 database that have no corresponding infusions in 

15 the second central server 108a database. 

If the medication identifier (e.g., bag ID) is not properly formatted, the second central 
server 108a causes the digital assistant 118 to display an invalid item notification at block 6210. 
Once the user acknowledges the invalid item notification (or the notification times out), the 
digital assistant 118 re-displays the screen prompting the user to scan a machine-readable 

2 0 identifier associated with the medication 124 to be resumed at block 6206. 

If the medication identifier (e.g., bag ID) is properly formatted at block 6208, the second 
central server 108a causes the digital assistant 1 18 to display a screen prompting the user to scan 
a machine-readable identifier associated with the patient 112 at block 6212. An example of a 
digital assistant display 1 18a prompting the user to scan a machine-readable identifier associated 

2 5 with the patient 112 is illustrated in FIGURE 36. The user may use the scanner of the digital 

assistant 118 to scan a barcode label on a patient wristband 112a. Alternatively, the user may 
manually enter the patient identifier into the digital assistant 118. The patient identifier is then 
sent to the second central server 108a for verification at block 6214. The second central server 
108a (or the digital assistant 118) then checks if a properly formatted patient identifier was 

30 received. Preferably, the second central server 108a does not need to check if the patient 

identifier matches a current infusion in the second central server 108a database, because the 
purpose of the "remove pump" action is to remove associations from the first central server 109 
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database that have no corresponding infusions in the second central server 108a database. 
However, the second central server 108a (or the digital assistant 118) may check if the patient 
identifier matches the patient 112 selected in block 6202. 

If the patient identifier (e.g., wristband ID) is not properly formatted, or the patient 
5 identifier does not match the patient 112 selected in block 6202, the second central server 108a 

causes the digital assistant 1 18 to display an invalid patient notification at block 6216. Once the 
user acknowledges the invalid patient notification (or the notification times out), the digital 
assistant 118 re-displays the screen prompting the user to scan a machine-readable identifier 
associated with the patient 1 12 at block 6212. 

10 If the patient identifier (e.g., wristband ID) is properly formatted and matches the patient 

1 12 selected in block 6202 at block 6214, the second central server 108a transmits a "stop alarm 
routing" XML document to the first central server 109 at block 6217. The "stop alarm routing" 
XML document includes the patient identifier (e.g., wristband ID), the medication identifier 
(e.g., bag ID), a completion URL, and a cancellation URL. The completion URL is a network 

15 address used if the pump 120 is successfully removed. The cancellation URL is a network 

address used if the "remove pump" action fails or is cancelled. 

Once the first central server 109 receives the "stop alarm routing" XML document, the 
first central server 109 determines if the "stop alarm routing" XML document is valid at block 
6224. For example, the first central server 109 may check if any data normally expected in a 

20 "stop alarm routing" XML document is missing from the received "stop alarm routing" XML 

document. If the first central server 109 determines that the "stop alarm routing" XML 
document is not valid, the first central server 109 causes the digital assistant 118 to display an 
error message indicating to the user that the "stop alarm routing" action could not be executed at 
block 6226. This display may include a reason such as which data was missing from the "stop 

25 alarm routing" XML document. After the user presses an "OK" button to acknowledge the error 

message, the first central server 109 returns a failure code to the second central server 108a via 
the cancellation URL at block 6228. 

If the first central server 109 determines that the "stop alarm routing" XML document is 
valid, the first central server 109 initiates the channel scanning process 5730. Generally, the 

30 channel scanning process 5730 prompts the user to scan a machine-readable identifier associated 

with the pump channel currently associated with the pump 120 to be removed and determines if 
the scanned channel is associated with the patient identifier and the medication identifier (as 
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described in detail above with reference to FIGURE 58. If the scanned channel is not associated 
with the patient identifier and the medication identifier, the "remove pump" action is cancelled. 
In such an event, the first central server 109 returns a cancel code to the second central server 
108a via the cancellation URL at block 6228. 
5 If the scanned channel is associated with the patient identifier and the medication 

identifier (i.e., the channel is valid), the first central server 109 causes the digital assistant 118 to 
display a message indicating the patient 112 and infusion associated with this action at block 
6232. Preferably, the PDA display also includes a "Continue" button and a "Cancel" button. In 
this manner, the user may manually stop the indicated infusion and then press the "Continue" 

10 button to inform the first central server 109 to check if the correct infusion was actually stopped. 

Alternatively, the user may press the "Cancel" button, at which point the first central server 109 
returns a cancel code to the second central server 108a via the cancellation URL at block 6228. 

If the user presses the "Continue" button, the first central server 109 determines if the 
infusion was stopped by reading status information sent to the first central server 109 by the 

15 pump 120 at block 6234. If the infusion was not stopped, the first central server 109 causes the 

digital assistant 1 18 to display a warning message indicating that the infusion was not stopped at 
block 6236. Preferably, the display also includes an "Continue" button and a "Cancel" button. 
If the user presses the "Cancel" button, the first central server 109 returns a cancel code to the 
second central server 108a via the cancellation URL at block 6228. 

20 If the user presses the "Continue" button, the first central server 109 attempts to remove 

the database association between the patient identifier, the medication identifier, and the channel 
identifier for either the primary infusion or the piggyback infusion, but preferably not both at 
block 6240. If the user wants to stop alarm routing associated with both a primary infusion and 
a piggyback infusion running on a channel, the user may execute the "remove pump" action 

25 twice, once for each infusion. If the first central server 109 is not successful in removing the 

database association at block 6242, the first central server 109 returns a failure code to the 
second central server 108a via the cancellation URL at block 6228. If the first central server 
109 is successful in removing the database association at block 6242, the first central server 109 
returns a success code to the second central server 108a via the completion URL at block 6244. 

30 The first central server 109 removes the association between the patient identifier, the 

medication identifier, and the channel identifier for the selected infusion only if a "remove 
pump" action is successful. Otherwise, the association is maintained. The second central server 
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108a need not update the status of the "removed" infusion upon receiving a success code from 
the first central server 109. 
Secure Communication Process 

As described above, the system may include a plurality of digital assistants 118 and a 
plurality of medical devices (e.g., infusion pumps 120) communicating over a wired or wireless 
network. Because some of the data being transmitted is confidential medical data, the data is 
preferably encrypted and only communicated in the clear to authorized users and devices. In 
order to setup a new digital assistant 118 or medical device 120, a commissioning phase of the 
authentication process may be performed. Each time a commissioned device is powered up, an 
authentication process is preferably performed in order to verify communication is occurring 
with an authorized device and/or user. Once a device and/or user is authenticated, secure one- 
way and/or two-way communication may occur in order to pass parameters, instructions, data, 
alarms, status information, and any other type of information between digital assistants, medical 
devices, and/or servers. 

Referring to FIGURE 63, a digital assistant commissioning phase (i.e., server 
registration phase) of a secure communication process 6300 begins at block 6302 when the first 
central server 109 creates a digital assistant user account. For example, the digital assistant user 
account may be established using Microsoft Active Directory in a well-known manner. The 
first central server 109 then generates a digital certificate for the digital assistant 118 at block 
6304. The digital certificate may be generated in any manner. For example, the digital 
certificate may be generated at the first central server 109 using Microsoft Digital Certificate 
Services in a well-known manner. The digital certificate preferably includes the digital 
assistant's public key digitally signed using the first central server' s'private key. In other words, 
the first central server 109 is acting as the certification authority (CA) for the digital assistant's 
digital certificate. Once the digital certificate is generated, the first central server 109 maps the 
digital certificate to the user account at block 6306. 

The digital assistant's digital certificate and the digital assistant's private key are then 
sent by the first central server 109 at block 6308 to the digital assistant 118 at block 6310. 
Preferably, the digital assistant's digital certificate and the digital assistant's private key are sent 
to the digital assistant 118 via a secure connection. For example, an RS-232 cable that is not 
connected to any other devices may be used. In addition, the first central server's digital 
certificate is sent by the first central server 109 at block 6312 to the digital assistant 118 at block 
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6314. Again, the first central server's digital certificate is preferably sent to the digital assistant 
118 via a secure connection such as an RS-232 cable that is not connected to any other devices. 
At this point, the digital assistant 118 is commissioned (i.e., registered with the server). 

Of course, any method of communicating with the digital assistant 118 may be used. In 
5 one example, the digital assistant's private key may be stored in a memory associated with the 

digital assistant 118 (e.g., an EPROM) at the time the digital assistant 118 is manufactured. In 
addition, each digital assistant 118 may have the same private key, with different identification 
codes used to distinguish one digital assistant 118 from another. 

Each time a commissioned digital assistant 118 is turned on, the digital assistant 118 and 

10 the first central server 109 must perform an authentication process in order to move from an 

unsecured wireless connection to a secured wireless connection. In the example illustrated, the 
digital assistant 118 establishes an unsecured 802.11 (wireless Ethernet) connection with the 
first central server 109 at block 6316 and block 6318. Of course, any type of connection may be 
used, such as a wired connection or a connection using another protocol. 

15 Turning to FIGURE 64, at block 6402 the digital assistant 118 sends a request to the first 

central server 109 to establish a secure connection. The first central server 109 receives the 
digital assistant's request to establish a secure connection at block 6404. The first central server 
109 responds to the request to establish a secure connection at block 6406 by sending a copy of 
the first central server's digital certificate to the digital assistant 118 over the unsecured 

2 0 connection. The digital assistant 118 receives the first central server's digital certificate at block 

6408. 

The digital assistant 118 uses the first central server's digital certificate to authenticate 
the first central server 109 at block 6410. In addition, at block 6412 the digital assistant 118 
uses the first central server's digital certificate to retrieve an embedded uniform resource locator 
2 5 (URL) associated with the first central server 109. The digital assistant 118 can now request 

data and services from the retrieved URL knowing it is talking to the real first central server 
109. 

Next, at block 6414 the first central server 109 sends a request to the digital assistant 118 
to establish the other half of the secure connection. The digital assistant 118 receives the first 
30 central server's request at block 6416. The digital assistant 118 responds to the request to 

establish a secure connection at block 6418 by sending a copy of the digital assistant's digital 
certificate to the first central server 109. The first central server 109 receives the digital 
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assistant's digital certificate at block 6420. 

The first central server 109 uses the digital assistant's digital certificate to authenticate 
the digital assistant 118 at block 6422. The first central server 109 can now communicate with 
the digital assistant 118 knowing it is talking to a commissioned digital assistant 118. In 
5 addition, turning to FIGURE 65, the first central server 109 establishes what files this digital 

assistant is authorized to access by mapping a session for the digital assistant user account to an 
active directory at block 6502. 

Now that the digital assistant 118 is communicating with the first central server 109 over 
a secure connection, and the digital assistant 118 is cleared to access certain files on the first 

10 central server 109, at block 6504 the digital assistant 118 may establish a secure communication 

session with the first central server 109 by accessing the URL retrieved from the first central 
server's digital certificate. The first central server 109 also establishes the secure 
communication session at block 6506. In addition, an application on the first central server 109 
verifies the digital assistant 118 belongs to the appropriate active directory at block 6508. 

15 Although the digital assistant 118 may now be authenticated, the first central server 109 

still does not know the identity of the user using the digital assistant 118. This is important 
because some users may have different access rights than other users, and certain alarms and 
other data are only sent to specific users. Accordingly, an application on the first central server 
109 may request a user name and password from the user of the digital assistant 118 at block 

20 6510. Once the digital assistant 1 18 receives the request for a user name and password at block 

6512, the digital assistant 1 18 retrieves a user name and password from the user via a prompt on 
the digital assistant display 118a at block 6514. The user name and password are then sent by 
the digital assistant 1 18 at block 6516 and received by the first central server 109 at block 6518. 
The application on the first central server 109 may then authenticate the user at block 6520. 

25 Once the user is authenticated on one server (e.g., the first central server 109), the 

authentication credentials may be used to automatically authenticate the digital assistant 118 on 
another server (e.g., second central server 108a). In one example, a user may only be 
authenticated if the user is authenticated on both the first central server 109 and the second 
central server 108a. Accordingly, the user name and password are preferably synchronized 

30 between the first central server 109 and the second central server 108a whenever a user name or 

password is created or modified. 

After authenticating the user, the first central server 109 preferably returns a token that 
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will be unique to the session between the user and the first central server 109. This session 
token is passed with each request (e.g., in an HTTP header or as a cookie) made to the first 
central server 109 as a means of authenticating the origin of the request and hence the 
destination of the response. Once this token is in place, the digital assistant 118 may roam from 
5 one wireless access point 1 14 to another seamlessly. 

Turning to FIGURE 66, the medical device commissioning phase (i.e., server 
registration phase) of the process 6300 begins at block 6602 when the first central server 109 
creates a medical device user account. For example, the medical device user account may be 
established using Microsoft Active Directory in a well-known manner. The first central server 

10 109 then generates a digital certificate for the medical device 120 at block 6604. The digital 

certificate may be generated in any manner. For example, the digital certificate may be 
generated at the first central server 109 using Microsoft Digital Certificate Services in a well 
known manner. The digital certificate preferably includes the medical device's public key 
digitally signed using the first central server's private key. In other words, the first central 

15 server 109 is acting as the certification authority (CA) for the medical device's digital 

certificate. Once the digital certificate is generated, the first central server 109 maps the digital 
certificate to the user account at block 6606. 

The medical device's digital certificate and the medical device's private key are then 
sent by the first central server 109 at block 6608 to the medical device 120 at block 6610. 

2 0 Preferably, the medical device's digital certificate and the medical device's private key are sent 

to the medical device 120 via a secure connection such as an RS-232 cable that is not connected 
to any other devices. In addition, the first central server's digital certificate is sent by the first 
central server 109 at block 6612 to the medical device 120 at block 6614. Again, the first 
central server's digital certificate is preferably sent to the medical device 120 via a secure 

2 5 connection such as an RS-232 cable that is not connected to any other devices. At this point, the 

medical device 120 is commissioned (i.e., registered with the server). 

Of course, any method of communicating with the medical device 120 may be used. In 
one example, the medical device's private key may be stored in a memory associated with the 
medical device 120 (e.g., an EPROM) at the time the medical device 120 is manufactured. In 

3 0 addition, each medical device 120 may have the same private key, with different identification 

codes used to distinguish one medical device 120 from another. 

Each time a commissioned medical device 120 is turned on, the medical device 120 and 
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the first central server 109 must perform an authentication process in order to move from an 
unsecured wireless connection to a secured wireless connection. In the example illustrated in 
FIGURE 67, the medical device 120 establishes an unsecured 802.11 (wireless Ethernet) 
connection with the first central server 109 at block 6702 and block 6704. Of course, any type 
of connection may be used, such as a wired connection or a connection using another protocol. 

Next, at block 6706 the medical device 120 sends a request to the first central server 109 
to establish a secure connection. The first central server 109 receives the medical device's 
request to establish a secure connection at block 6708. The first central server 109 responds to 
the request to establish a secure connection at block 6710 by sending a copy of the first central 
server's digital certificate to the medical device 120 over the unsecured connection. The 
medical device 120 receives the first central server's digital certificate at block 6712. 

The medical device 120 uses the first central server's digital certificate to authenticate 
the first central server 109 at block 6714. In addition, at block 6716 the medical device 120 uses 
the first central server's digital certificate to retrieve an embedded uniform resource locator 
(URL) associated with the first central server 109. The medical device 120 can now request 
data and services form the retrieved URL knowing it is talking to the real first central server 
109. 

Next, at block 6718 the first central server 109 sends a request to the medical device 120 
to establish the other half of the secure connection. The medical device 120 receives the first 
central server's request at block 6720. The medical device 120 responds to the request to 
establish a secure connection at block 6722 by sending a copy of the medical device's digital 
certificate to the first central server 109. The first central server 109 receives the medical 
device's digital certificate at block 6724. 

Turning to FIGURE 68, the first central server 109 uses the medical device's digital 
certificate to authenticate the medical device 120 at block 6802. The first central server 109 can 
now communicate with the medical device 120 knowing it is talking to a commissioned medical 
device 120. In addition, the first central server 109 establishes what files this medical device 
120 is authorized to access by mapping a session for the medical device user account to an 
active directory at block 6804. 

Now that the medical device 120 is communicating with the first central server 109 over 
a secure connection, and the medical device 120 is cleared to access certain files on the first 
central server 109, at block 6806 the medical device 120 may establish a secure communication 
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session with the first central server 109 by accessing the URL retrieved from the first central 
server's digital certificate. The first central server 109 also establishes the secure 
communication session at block 6808. In addition, an application on the first central server 109 
verifies the medical device 120 belongs to the appropriate active directory at block 6810. 
5 Although the medical device 120 may now be authenticated, the first central server 109 

still does not know the identity of the user using the medical device 120. In many instances, no 
user will be associated with a medical device 120. In some applications, this may be important 
because some users may have different access rights than other users. In addition, a medical 
device may have different "roles." For example, a medical device may have a "one-way 
10 communication" role or a "two-way communication" role. In this manner, a medical device 120 

capable of two-way communication may be placed in a system that expects only one-way 
communication devices. Similarly, a system that is capable of handling both one-way 
communication devices and two-way communication devices may need to be told the type of 
device that is connected. 

15 Accordingly, an application on the first central server 109 may request a user name and 

password from the user of the medical device 120 at block 6812. Once the medical device 120 
receives the request for a user name and password at block 6814, the medical device 120 
retrieves a user name and password from the user via a prompt on the medical device 120 or an 
associated digital assistant display 118a at block 6816. The user name and password are then 

20 sent by the medical device 120 (or other device) at block 6902 of FIGURE 69 and received by 

the first central server 109 at block 6904. The application on the first central server 109 may 
then authenticate the user at block 6906. 

Once the user is authenticated on one server (e.g., the first central server 109), the 
authentication credentials may be used to automatically authenticate the user on another server 

2 5 (e.g., second central server 108a). In one example, a user may only be authenticated if the user 

is authenticated on both the first central server 109 and the second central server 108a. 
Accordingly, the user name and password are preferably synchronized between the first central 
server 109 and the second central server 108a whenever a user name or password is created or 
modified. 

30 After authenticating the user, the first central server 109 preferably returns a token that 

will be unique to the session between the user and the first central server 109. This session 
token is passed with each request (e.g., in an HTTP header or as a cookie) made to the first 
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central server 109 as a means of authenticating the origin of the request and hence the 
destination of the response. 

Secure one-way communications may now be sent from the medical device 120 to the 
digital assistant 1 18. For example, the medical device 120 may report settings, generate alarms, 
5 etc. In the example illustrated, the medical device 120 determines data to be sent to the digital 

assistant 118 via the first central server 109 at block 6908. This data is then sent to the first 
central server 109 at block 6910 and received by the first central server 109 at block 6912. The 
first central server 109 may then determine which user(s) are authorized to receive this data at 
block 6914 and which digital assistant(s) 118 those users are currently associated with at block 

10 6916. For example, a lookup table stored in the first central server 109 database may be used. 

The first central server 109 then sends the data to the appropriate digital assistant(s) 118 
at block 6918 and the digital assistant(s) 118 receive and display the data at block 6920. In 
addition, secure two-way communications may be accomplished. For example, a digital 
assistant 1 18 and/or the first central server 109 may send data, commands, setup information, or 

15 any other type of information to the medical device 120. 

Multi-Purpose User Interface 

Referring to Figure 70, several further embodiments are disclosed, each of which can be 
used to implement the various features advantages of the above identified and described 
embodiments, as one of ordinary skill the art would understand. Specifically, Figure 70 shows a 

2 0 multi-purpose user interface 118' for the healthcare system referred to herein. A plurality of 

user interfaces 118' as well as the user interfaces or digital assistants 118, referred to above, can 
be used within the system as well. The system also has a plurality of medical devices 120, 
which, as mentioned, can be a controller for a medical device, such as a controller for an 
infusion pump, or can be a pumping mechanism, such as a MEMS pump integral with a line set 

2 5 (see Figures 1, 3, and 53), as well as other types of medical devices. The user interface 1 18' has 

a housing, a processor, a memory, and a communications interface. The communications 
interface is preferably a RF transmitter/receiver for providing communication between the user 
interface 118' and the medical device 120. In one embodiment, the user interface 118' can 
receive information from the medical device 120 about the status of the operation of the medical 

3 0 device, including alarms, alerts, and other information, including but not limited to maintenance 

information. In another embodiment, the user interface 1 18' can both receive medical 
information, and send or transmit control information and/or parameters to the medical devices 
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120 through the communications interface, for controlling the operation of the medical devices 
directly or through the programming instructions that are used by the medical device 120 to 
control itself. For example, this control information can include high level instructions such as 
volume to be infused and infusion rate parameters in the case of an infusion pump medical 
5 device, or the control information can be low level instructions used to directly control the 

medical device 120. 

Similar to embodiments discussed herein above, the first central computer can 
communicate directly with the medical device in a manner disclosed in these previous 
embodiments, with respect to at least the one way communication and the two way 

10 communication embodiments. In an even further embodiment, the first central computer can 

send the medical device control information to provide the direct operating commands for the 
medical device 120 to follow. For example, in the previous embodiments, this control 
information can include high level instructions such as volume to be infused and infusion rate 
parameters in the case of an infusion pump medical device, and in the present embodiment, the 

15 control information can be low level instructions used to directly control the medical device 120, 

such as a MEMS pump shown in Figure 53. An example of the high level parameters can 
include an infusion rate, a volume to infuse, and a start time for an infusion pump, and in the 
case of low level instructions, a start command, a speed to run at, and a stop command, etc. 
The communications interface also provides for communication between the user 

20 interface 118' and the first central computer 109 in a manner which can include at least the types 

of communications referred to herein above. The user interface 118' also has a display for 
displaying a medical prompts of the types also referred to herein above for the various different 
types of actions that a clinician or other care giver can take mentioned herein above, as well as 
other actions and prompts therefore. The user interface 118' further can display medical 

2 5 information received from the first central computer 109, as explained herein above, as well as 

other medical information. 

The housing of the user interface 118' can be structured to have a shape, size and 
components / elements which allow the user interface to physically connect to one or more of 
the plurality of medical devices 120. The shape, size, and components of the housing allow for 

30 the user interface to be removeably connected with the medical devices 120. The user interface 

118' can be programmed with a thin-client operating system for operating the user interface 
118'. Alternatively, the user interface 1 18' can be programmed with a thick client operating 
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system or other operating system. 

As described in previous embodiments, a task or computer program, such as a listener 
task can be sent by the first central computer 109 to the user interface for the user interface 118' 
to listen for medical information from the first central computer 109. The first central computer 
109 can also send a second task or computer program, such as a listener task, to the user 
interface 118' for the user interface 118' to listen for medical information from directly from the 
medical device 120. The system can be arranged such that the communications take place 
between the user interface 118' and the first central computer 109, and between the medical 
device and the first central computer, and even between the user interface 118' and the medical 
device 120, through a standard wireless network having a plurality of wireless access points as 
described herein above. 

The user interface 1 18' can also communicate and interact with one medical device 120 
in the manner described above, the user interface can communicate and interact with a plurality 
of medical devices 120 in a one to many manner. Likewise, a plurality of user interfaces 118' 
can be used within the system. The user interfaces 118' are associated with particular medical 
devices 120 and a record of this association can be kept track of at the first central computer 
109, or elsewhere. The user interface 118' can be programmed to display or receive instructions 
to display a selection prompt on the display for selecting at least one medical device 120 to 
associate the user interface with. The user of the user interface 118' can select the medical 
device on the display or by scanning a bar code or reading some other medical device identifier, 
as described herein above. As described, the medical devices 120 can be of different types. In 
order to handle different types of medical devices 120, the user interface can be programmed or 
receive instructions to allow the user interface to operate and communicate with the different 
types of medical devices which may be utilized within the system. A first personality (the 
screens, prompts, and other instructions and commands needed for a proper interaction with the 
user interface, the user, the medical device and the first central computer) can be programmed 
and stored in the memory of the user interface 118', the first central computer 109, and /or the 
other devices for later use. Likewise, other personalities can be programmed and stored as well. 
When the identification of the medical device is received, the processor can automatically 
program the user interface 118' and/or the other devices to operate in accordance with the first 
personality type. 

The user interface 118' can also be programmed or receive instructions, such as a script 
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to run, which can send a request to the first central compute 109 to locate an available and 
qualified clinician for the user interface 109, in order to gain the attention of one or more 
clinicians in the care giving facility. The first central computer 109 can then send a message to a 
clinician device, such as device 118, that the user interface 118' is in need of attention. The first 
central computer 109 and/or the user interface 118' can then receive a response from the 
clinician device 118 that the clinician will attend to the user interface 118'. 

All or at least a portion of all of the communications can be sent in a secure fashion, as 
described above herein. In addition, the system can utilize web services for communication with 
the medical devices, the user interfaces, and other central computers, such as a second central 
computer 108a, as described above herein. For example, the first central computer can send one 
or more tasks to the user interface 118' and/or the medical device 120, including but limited to a 
listen task, an alarm task, an alert task, a message task, a low battery task, an occlusion task, a 
pre-occlusion task, a bolus task, a KVO task, a STAT task, a change order task, a new order 
task, a lab result task, an MRI results task, update task, change in telemetry data task, a change 
in vital signs task, a doctor contact task, a patient contact task, a loss of communications task, a 
relay of message from other device task; and a new rate task. 

Vital Siens and Central Monitoring Integrated With Central System And Pump Controllers 

Referring to Figures 71-75, the system 100 described above, including the various 
embodiments thereof, can be integrated with vital sign(s) monitoring devices 7104 and central 
monitoring systems 7110. In one embodiment, infusion pumps and/or controllers 7114 
therefore are connected to a network 7120, such as a wired or wireless local area network, along 
with the vital sign(s) monitoring devices 7104 and the central monitoring system(s) 7110. A 
central computer 7130, which can be the same as or similar to the central computer 108 
(including the separation of functions into a plurality of central computers 108a, 109) can also 
be connected to the network 7120 and provide the same or similar functionality of the previous 
embodiments described above in relation to the pumps 7114 and in relation to the other devices 
and functionality described above. In general, clinicians using this arrangement will have the 
ability to correlate infusion pump data with vital signs, arrhythmias and/or other hemodynamic 
parameters and data. This arrangement also allows for infusion pump alarm and/or alert 
notification and management thereof. This arrangement further allows for the ability to change 
infusion pump settings from the central station. This arrangement further allows for the 
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comparison of drug label, rate/dose, and/or concentration programmed on infusion pumps to a 
pre-defined list of high and low dose and/or concentration limits and generates a message at the 
central station if limits are exceeded. 

Specifically, in one embodiment, during critical and/or non-critical patient events or 
alarm conditions, a clinician can view, manage and/or print out infusion pump data mentioned in 
any or all of the prior embodiments, as such data correlates with hemodynamic parameters and 
arrhythmias through the central computer 7130, through devices connected thereto, such as 
handheld interface devices mentioned in prior embodiments. Exemplar screens are shown in 
Figures 72-75. Vital signs data can be tracked by the vital signs monitoring devices 7104, and 
the vital signs data can be sent to and received by the central computer 7130. This information 
will be automatically recorded in the patient's electronic medical record (eMAR) at the central 
computer 7130. As indicated above, the central computer 7130 tracks pump data as well 
received from the infusion pumps 71 14. The integration of infusion pump data with the vital 
signs data at the central computer 7130 allows for correlation of the infusion pump data and at 
least hemodynamic parameters, and other vital signs data and parameters. As indicated in prior 
embodiments, from a computer screen connected to the central computer 7130 at a central 
location or from a transportable interface device (such as a handheld device), the clinician 
would be able to identify which patients have active infusions on infusions pumps 7114 and/or 
how many channels are infusing for such pumps 71 14. In addition, the clinician could view a 
map of infusion pump locations on her/his unit. Such information could include the pump 
channel, the name of the medication/solution being delivered on such pump channel, the 
delivery rate and dose for the medication/solution being delivered on such channel, the volume 
of medication/solution to be infused, the volume already infused and/or the remaining volume to 
be infused, and the infusion time remaining. At least this information could be displayed for 
each infusion, as shown in Figures 72-75. For other types of medication delivery pumps, other 
than infusion pumps, the same type of information could be provided. Other details about an 
infusion or other delivery could be accessed as well. The central computer screen and/or 
transportable interface device could also provide for the communication of audible and/or visual 
notifications of alarm and alert conditions and infusion/other delivery status, such as "standby", 
"running", and/or "stopped". Through such central computer screens and/or transportable 
interface devices, clinicians could silence alarm and/or alert conditions, and could have a "near 
end" of the infusion or delivery alert for infusions or other delivery type. Alarms and alerts 
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notification and display thereof on the central computer screen and/or transportable interface 
devices could be prioritized and could have an escalation feature associated with them, as can be 
understood from the embodiments described above. For example, caregivers using a central 
computer screen and/or transportable interface device could be alerted through such screen 
and/or interface that a pump 71 14 is being or was programmed outside of an acceptable limit on 
medication/solution dose, rate, and/or concentration. In response thereto, or in general, the 
clinician could then be given the ability to modify the pump settings from the central computer 
screen and/or the transportable interface device. 

The central computer screen and/or transportable interface device provides for viewing 
of infusion pump data at the same time as other hemodynamic parameters, thereby providing a 
clinician a more complete picture of the clinical state of a patient, and a second look or double 
check of programmed infusion parameters. As mentioned, the central computer screen and/or 
transportable interface device also provides the ability to program/manage infusion pumps 7114, 
such as for example, clearing the volume infused at the end of a shift, provides notification of 
infusion pump alarms and alerts, provides for prioritized alarms and alerts as well as the 
escalation thereof, provides for the ability to silence alarms and alerts, provides access to 
documentation of titration history (vital sign trends associated with flow rate changes), provides 
a direct link to eMAR and clinical documentation, provides information on comparisons of drug 
label, rate/dose, or concentration data programmed on infusion pump to a pre-defined list of 
high and low dose or concentration limits (through the central computer 7130 or otherwise) and 
provides notification if limits are exceeded, and provides a near end of infusion alert for critical 
or other infusions, all of the above including tracked data and/or real time data, as appropriate. 

Printers connected to the central computer 7130 and/or central monitor 71 10 can provide 
printouts as to the real time and/or tracked data, such as for hemodynamic and/or arrhythmia 
events along with correlating infusion pump data, for infusion pump data during code blue 
situations (all changes made on infusions correlated with hemodynamic and arrhythmia events), 
and/or for end of shift summary, for snapshots of pump data correlated with vital signs during 
alarm conditions (either pump alarms or alarms for hemodynamic changes or arrhythmias). 
This printable data can also be accessed through the central computer screen and/or through the 
transportable interface device. Maps or other ways to identify infusion device and other device 
locations can be provided through the screens, interfaces and printouts, for example, on a 
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particular unit basis and/or on an entire hospital basis, with or without availability data of such 
devices. 

All of the display and control functionality available through the central computer 
screens and/or transportable interface devices described above, such as for example, receiving 
and displaying data from the vital signs monitors 7104 and the infusion pumps 71 14 in real 
time, could also be performed through a central computer screen and/or transportable interface 
device (handheld or otherwise) connected to and/or through the central monitor 71 10. The 
displayed and/or printable information can appear in various formats, such as for example 
graphical and/or tabular forms. The integration between monitor and pump data and 
functionality described herein can also apply to the integration with the data and functionality of 
other devices, such as for example, monitor and ventilator data and functionality, and monitor 
and intraortic balloon pump data and functionality. 

Medication Delivery Data Tracking, Analyzing and Reporting 

Referring to Figures 76- 128, the system 100 of the prior embodiments can generate a set 
of reports that will be of value to clinicians, administrators or risk managers/safety officers in 
viewing healthcare and medication delivery data, such as for example, data related to pump 
usage and medication errors. Examples of some of the types of reports that can be provided 
include a near miss summary, summary of alarms and alerts, total number of pump infusions, 
flow rate history, pump infusion comparison summary, pump Guardian dose/rate out of limits 
alert warnings and overrides summary, and other reports. The ability to view and print this type 
of data is beneficial in identifying and tracking actual and potential medication errors and near 
misses. It could also be used to look at response time of clinicians to critical pump alarms. 
Knowing the total number and type of pump infusions per unit is an indication of patient acuity 
and could help with staffing decisions. For pumps, such as for example, those made by Baxter 
Heathcare, Inc. under the name COLLEAGUE that can have a feature named GUARDIAN (see 
http://www.baxter.com/products/medication management/infusion pumps/large volume 
infusion pumps/colleague/index. html\ the system would track pump out of limits alert 
overrides to help pharmacists and other healthcare professionals in determining if the limits for 
specific medications require adjustment. Another example includes hospitals using data on 
numbers of infusions/ pump usage to help make purchasing decisions regarding number of 
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pumps required per unit. 

Specifically, the reports will at least allow clinicians to view and print a history of flow 
rate changes made on the Colleague Pump for a specific medication on a specific channel; allow 
hospitals/clinicians to view and print information regarding the total number of infusions hung 
on pumps, with connectivity to central computers for the unit(s), medication(s), and time period 
selected; allow hospitals/clinicians to view and print near misses related to the five rights of 
medication administration/management (right patient, right drug, right dose, right time, and 
right route), with reason codes; allow hospitals/clinicians to view and print a history of pump 
alarms and KVO alerts and resolutions by unit(s), patient(s), medication(s), specific alarm 
condition, and time period, including the total number of alarms and KVO alerts escalated to a 
charge nurse that can also be sorted by unit and/or alarm condition; allow hospitals/clinicians to 
view and print a flow rate comparison summary by patient(s) and medication(s), including all 
matches, mismatches and mismatch overrides; allow hospitals/clinicians to view a history of 
pump alarms and KVO alerts and when silenced/cleared, specific unit(s) and average time to 
resolve; allow hospitals/clinicians to view and print pump dose/rate out of limits alert summary 
including when the warning was accepted and overridden and when the pump was 
reprogrammed as a result of the warning, including an out of limit summary report by specific 
medication on infusions hung with the use of handheld interface devices connected to central 
computers in communication with such pumps, as described in prior embodiments. While the 
reports that will be shown as examples in FIGURES 76-128 have certain particularities about 
each of them, these reports could vary in many different ways, such as for example, varying 
layouts/formats (for example: portrait vs. landscape), varying sort order and/or group 
definitions, varying graph types, varying the type and the amount of data shown, varying the 
title or identification of the reports, and/or varying the search/criteria options for changing data 
that will be shown. The system could also provide for a print preview option. 

More specifically, with reference to prior embodiments, the system includes a plurality 
of interface devices, such as the various types described herein above. The interface devices 
each can have a receiver, such as a bar code scanner, RF scanner, or other receiver described 
herein above, for receiving identifier data. The identifier data can also be of the type described 
herein above. The system also has a central computer in communication with the plurality of 
interface devices over a communications network for receiving and storing the identifier data 
and all information associated with such identifier. For example, a bar code on a line set 
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solution bag can identify the medication(s) (solution(s)) in the bag. Information, such as for 
example, which infusion pump the bag was used with, which nurse connected the bag to the 
infusion pump, whether the solution in the bag matched with the Order for the patient, which 
patient the bag was used with, can be considered to be associated with the identifier data and be 
5 a part of such identifier data. This identifier data can also be considered as medical pump data 

when a medical pump is involved. The interface devices can have an interface screen for 
displaying a manipulated version of the identifier data. Further, the system can have a plurality 
of medical pumps, such as for example infusion pumps, each having medical pump data 
associated therewith, as mentioned above. The central computer is in communication with the 

10 plurality of medical pumps over a communications network, as described above herein, for 

receiving and storing the medical pump data. The interface devices also have an interface 
screen for displaying a manipulated version of the medical pump data. Upon request for 
manipulated data from an interface device, or as a result of some other occurrence, the central 
computer can add, calculate, combine, compare, analyze, compute, separate, tabulate and/or 

15 perform some other processing function to and/or on the identifier data and/or medical pump 

data and/or the use thereof in delivering medication. This manipulated information can then be 
transmitted to the interface device for review by a caregiver. 

This manipulated information, manipulated version of the medical pump data, and/or 
manipulated version of the identifier data can take on many different forms, such as for 

20 example, in different types of reports presented in various different formats. The following 

describes several exemplar preferred embodiments of such reports, including the presentation of 
manipulated information, manipulated version of the medical pump data, and/or manipulated 
version of the identifier data. 

Near Miss Summary Report 

2 5 Referring to Figures 76-77, an error near miss summary report is shown which indicates 

totals of near misses at administration for the patient's five rights for each unit and/or for all 
units in the hospital. Figure 76 shows this information for multiple units and totalizes the data, 
and Figure 77 shows this information for a single chosen unit. 

The following exemplar data/information can be included in this report: 

30 



Header/Label 


Description 


Data Type ! 


Total 


Total Med Administrations in that 


Numeric 
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Administrations 


Unit (with & without errors) 




Total Wrong 


Total of # Wrong Drug + #Wrong 
Patient + #Wrong time + #Wrong 
Route + #Wrong Rate (Near Miss) + 
#Wrong Dose (Med Error) 


Numeric 


# Wrone Dru£ 


Total Scan Errors nn wrntip dm*? for 
all patients in the Unit 
For Example: Nurse scans Multiple 
Vitamin Injection when the order is 
for (the system expects) Bel's 
Morphine Sulfate Injection This 
wrong scan is counted as part of# 
Wrong Drugs for Bel's Mophine 
Sulfate Injection. 


Nnmpric 


#• Wrong Patient 


Total Scan Errors on Patient for Unit 


Numeric 


# Wrong Time 


Total of early, late, expired, and 
missed med administrations 


Numeric 


# Wrong Route 


Total wrong route entered. This only 
applies to Infusions 


Numeric 


# Wrong Rate 
(Near Miss) 


Total #Resolved Rate Mismatches 
for Infusions only (equivalent of 
"Wrong Dose" for infusions) 


Numeric 


# Wrong Dose 
(Med Error) 


Total Partial Dose Administrations 
(For Non-Infusions) 


Numeric 


Unit 


Name of Unit to which the Patient 
currently belongs (# Wrong Rate - 
Near Miss - see below for 
alternatives) 


Text 


Infusion / Non- 
Infusion 


Totals split as to whether the 
medication in the administration 
related to the Right being verified is 
an Infusion or non-Infusion. 


Text 



As indicated above, the reports in Figures 76 and 77 indicate that the system can break 
the data down by at least unit, infusion or medical pump data and non-infusion or identifier data. 
The system can allow for searching by at least date range and/or unit. In addition, the Wrong 
5 Route can be tracked and reported for both infusions and non-infusion orders. A caregiver may 

be required to enter the Route actually used at the time of administration to track this data. For 
Wrong Rate (Near Miss), the system could be set up to save if the nurse attempts to give a dose 
greater than what was ordered or could be set up to prevent the nurse from continuing with the 
administration workflow. Further, the system can count the # Resolved Rate Mismatches in the 
10 Wrong Rate (Near Miss) total, or track and report this data separately. For non-infusion Wrong 

Dose (Med Error) the system can allow for entry of a Partial Dose. For infusion Wong Dose 
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(Med Error), the system can be set up to not allow for the entry of a Partial Dose (i.e., less than 
amount ordered). The system can also be set up so that Unit is defined as that to which the 
Patient currently belongs for all categories except # Wrong Rate (Near Miss). For #Wrong Rate 
(Near Miss), the system can be set up so that the Unit is defined as the unit to which the Patient 
5 belonged when the Resolved Rate Mismatch occurred. For example, Patient A is in Unit X 

when the Infusion is hung and the Rate Mismatch occurs. Later Patient A is transferred to Unit 
Y. The Near Miss for the Rate Mismatch will be totaled under Unit X. Any other Near Misses 
for this Patient will be totaled under Unit Y. 

Near Miss Summary by Medication Report 
10 Referring to Figures 78-81, a near miss summary by medication report is shown, which 

lists totals of near misses and medication errors at administration for the patient's five rights by 
medication per unit or all units in the hospital. 

The following exemplar data/information can be included in this report: 



Header/Label 


Description 


Data Type 


Total 

Administrations 


Total Med Administrations in that 
Unit (with & without errors) 


Numeric 


Total Wrong 


Total of # Wrong Drug + #Wrong 
Patient + #Wrong time + #Wrong 
Route + #Wrong Rate (Near Miss) 
+ #Wrong Dose (Med Error) 


Numeric 


# Wrong Drug 


Total Scan Errors on wrong drug for 
all patients in the Unit 
For Example: Nurse scans Multiple 
Vitamin Injections when the order is 
for (the system expects) Bel's 
Morphine Sulfate Injection. This 
wrong scan is counted as part of# 
Wrong Drugs for Bel's Mophine 
Sulfate Injection. 


Numeric 


# Wrong Patient 


Total Scan Errors on Patient for 
Unit 


Numeric 


# Wrong Time 


Total of early, late, expired, and 
missed med administrations 


Numeric 


# Wrong Route 


Total wrong route entered. This 
only applies to infusions. 


Numeric 


# Wrong Rate 
(Near Miss) 


Total #Resolved Rate Mismatches 
for Infusions only (equivalent of 
"Wrong Dose" for infusions) 


Numeric 


# Wrong Dose 


Total Partial Dose Administrations 


Numeric 
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(Med Error) 


(For Non-Infusions only) 




Unit 


Name of Unit to which the Patient 
currently belongs (# Wrong Rate - 
Near Miss — see below for 
alternatives) 


Text 


Infusion / Non- 
Infusion 


Totals split as to whether the 
medication in the administration 
related to the Right being verified is 
an Infusion or non-Infusion. 


Text 


Medication 


Totals split per Medication and 
grouped by Infusion/Non-Infusion 
(see Notes below) 


Text 



As indicated above, the reports in Figures 78 and 79 indicate that the system can break 
the data down by at least unit, infusion or medical pump data, non-infusion or identifier data, 
and medication. The system can allow for searching by at least date range, unit, and/or item 
5 name, such as for example, a medication name. In addition, the Wrong Route can be tracked 

and reported for both infusions and non-infusion orders. A caregiver may be required to enter 
the Route actually used at the time of administration to track this data. For Wrong Rate (Near 
Miss), the system could be set up to save if the nurse attempts to give a dose greater than what 
was ordered or could be set up to prevent the nurse from continuing with the administration 

10 workflow. Further, the system can count the # Resolved Rate Mismatches in the Wrong Rate 

(Near Miss) total, or track and report this data separately. For non-infusion Wrong Dose (Med 
Error) the system can allow for entry of a Partial Dose. For infusion Wong Dose (Med Error), 
the system can be set up to not allow for the entry of a Partial Dose (i.e., less than amount 
ordered). The system can also be set up so that Unit is defined as that to which the Patient 

15 currently belongs for all categories except # Wrong Rate (Near Miss). For #Wrong Rate (Near 

Miss), the system can be set up so that the Unit is defined as the unit to which the Patient 
belonged when the Resolved Rate Mismatch occurred. The same example from the Near Miss 
Summary Report embodiment applies here as well. 

In one embodiment for Medications in relation to Infusions, business rules for 

2 0 summarizing Infusions by Med can work as follows: 1) if infusion has 1 Item/Medication in it, 

the data is counted under that Medication; 2) if a Mixed Infusion has 2 Items in it, the data is 
counted under the Additive rather than the Solution (for example, if Infusion is Dopamine + 
D5W, any near misses for this order are counted as Dopamine); 3) if Infusion has more than 2 
Items in it (for example, 2 Additives plus Solution), the infusion will be counted by its Order 
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Type (for example, Continuous Infusion, TPN, etc.). The report can display either the name of 
the drug in the infusion if the Infusion has 1 medication or can display the Order type if there 
are 2 or more ingredients. Further, for the Med Admin results, if the Order has 2 ingredients, 
the report can display the first ingredient. A further report can be provided, indicating the Top 
5 20 Meds used. For example, a bar chart displaying the Top 20 meds used over a particular 

Unit(s) and time span, in connection with (for example, on the same screen) the other reports or 
separate from the other reports. This type of report can be provided in various different forms, 
such as for example, in Bar Chart format. 
Scan Errors Report 

10 Referring to Figure 82, a scan errors report is shown, which lists all scan errors in the 

hospital for patients, items and containers. 

The following exemplar data/information can be included in this report: 



Header/Label 


Description 


Data Type 


Group 


User Group (e.g. Nurse - HandHeld 
/ Interface Device) 


Text 


Personnel 


Name of Nurse who caused the scan 
error 


Text 


Time 


Time of Scan error 


Date/Time 

(dd-mm-yyyy- 

hhrmm) 


System/Screen 


Name of BPCS application plus 
Screen on which the Scan error 
occurred 


Text 


Scan Error 
(Type/Error) 


Type of Scan error 
Description of scan error type 


Text 


Expected 


Value of expected scan - If patient 
related, include name of Patient. 
If Item, include Item name. 


Text 


Actual 


Actual scanned value - If patient 
related, include name of Patient. 
If Item, include Item name. 


Text 


Total 


Total Number of scan errors for the 
User for the selected time period 





15 

The system can break the data down by at least date range, date error occurred, user 
group (caregiver group/unit), user, and/or identifier type, such as for example, a bar code type. 
The identifier type can include at least container identifiers (for example, medication/supply cart 
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identifiers), encounter locators or identifiers (for example, patient identifiers), patient identifiers, 
and/or item scan identifiers (for example, medications, bags, other supply items). The system 
can allow for searching by at least date range, user group (caregiver group/unit), user, and/or 
identifier type. Figure 83 shows one example of a selection criteria screen that can be used to 
select the criteria for displaying the Scan Errors Report. 
Wrong Time Report 

Referring to Figures 84-87, a near miss wrong time / wrong time report is shown, which 
lists totals for wrong time of administrations per unit or all units in the hospital. 
The following exemplar data/information can be included in this report: 



Header/Label 


Description 


Data Type 


Total 

Administrations 


Total Med Administrations for the 
selected Unit(s) 


Numeric 


Total Wrong 
Time 


Total Med Administrations at the 
wrong time in that Unit (Total of 
Early, Late, Expired, and Missed) 


Numeric 


# Early Meds 


Total Early administrations 


Numeric 


# Late Meds 


Total Late administrations 


Numeric 


# Expired Meds 


Total administrations of Expired 
orders 


Numeric 


# Missed Meds 


Total missed med administrations 


Numeric 


Unit 


Name of Unit to which the Patient 
belonged when the Administration 
was done 


Text 


Infusion / Non- 
Infusion 


Totals split as to whether the 
medication in the administration is 
an Infusion or non-Infusion. 


Text 



As indicated above, the system can break the data down by at least unit, infusion, and/or 
non-infusions. The system can further allow for searching by at least date range and/or unit. 
The system can provide for display of Total Administrations separately from the table or in 
combination with the report of data. 

Wrong Time by Medication Report 

Referring to Figures 88-91, a near miss wrong time by medication / wrong time by 
medication report is shown, which lists totals of near misses for wrong time of administration by 
medication per unit or all units in the hospital. 

The following exemplar data/information can be included in this report: 
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Header/Label 


Description 


Data Type 


Total 

Administrations 


Total Med Administrations for the 
selected Unit 


Numeric 


Total Wrong 
Time 


Total Med Administrations at the 
wrong time in that Unit 


Numeric 


# Early Meds 


Total Early administrations 


Numeric 


# Late Meds 


Total Late administrations 


Numeric 


# Missed Meds 


Total missed med administrations 


Numeric 


Unit 


Name of Unit to which the Patient 
belonged when the Administration 
was done 


Text 


Infusion / Non- 
Infusion 


Totals split as to whether the 
medication in the administration is 
an Infusion or non-Infusion. 


Text 


Medication 


Totals split per Medication and 
grouped by Infusion/Non-Infusion 
(see Notes below) 


Text 



As indicated above, and as shown in Figures 88-91, the system can break the data down 
for these reports by at least unit, infusion or medical pump data, non-infusion or identifier data, 
5 and medication. The system can allow for searching by at least date range, unit, and/or item 

name, such as for example, a medication name. In one embodiment for Medications in relation 
to Infusions, business rules for summarizing Infusions by Med can work as follows: 1) if 
infusion has 1 Item/Medication in it, the data is counted under that Medication; 2) if a Mixed 
Infusion has 2 Items in it, the data is counted under the Additive rather than the Solution (for 

10 example, if Infusion is Dopamine + D5W, any near misses for this order are counted as 

Dopamine); 3) if Infusion has more than 2 Items in it (for example, 2 Additives plus Solution), 
the infusion will be counted by its Order Type (for example, Continuous Infusion, TPN, etc.). 
The report can display either the name of the drug in the infusion if the Infusion has 1 
medication or can display the Order type if there are 2 or more ingredients. Further, for the Med 

15 Admin results, if the Order has 2 ingredients, the report can display the first ingredient. The 

system can also provide for display of Total Administrations separately from the table or in 
combination with the report of data. In addition, although the number of Late Administrations 
for Continuous, Tapering, and TPN infusions can be tracked and reported, this information may 
not be useful data. In particular, if one administration is late, the rest should be as they are hung 

20 when the previous one ends. This information may be more useful for Intermittent infusions. 
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Wrong Time With Reason Codes Report 

Referring to Figures 92-93, a wrong time with reason code report is shown, which lists 
the administrations given at the wrong times - early, late, expired, and missed along with the 
reason associated with this wrong time. 

The following exemplar data/information can be included in this report: 



Header/Label 


Description 


Data Type 


Wrong Time 
Category 


Category of Wrong Time - Early, 
Late, Expired, and Missed 


Text 


Medication 


Name of Medication 


Text 


Reason 


Reason Code text associated with 
wrong time of administration 


Text 


Patient 


Name of Patient 


Text 


Order 


RX ID and description of the order 
(i.e. RX Text) 


Text 


Order Admin 
Time 


Date and Time Medication was 
Ordered for 


Date 

(dd-mm-yyyy 
hh:mm:ss) 


Admin Time 


Date and Time Medication was 
actually administered 


Date 

(dd-mm-yyyy 
hh:mm:ss) 


Nurse 


Name of Nurse who administered 
the Medication. 


Text 


Total 


Total number of Administrations for 
each Wrong Time Category 


Numeric 



As indicated above, and as shown in Figures 92-93, the system can break the data down 
for these reports by at least wrong time category (early, late, expired, missed), medication, 
reason code, and/or order administration time. The system can allow for searching by at least 
date range, unit, and/or medication. If the system tracks the nurse that was actually or was 
supposed to be assigned to a patient at the time the medication was supposed to be administered, 
then the system could provide a Nurse with Missed Meds report. 

Infusion Flow Rate History Report 

Referring to Figure 94, an infusion with flow rate history report is shown, which lists the 
history of flow rates for medication hung on infusion pumps. 

The following exemplar data/information can be included in this report: 
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Header/Label 


Description 


Data Type 


Unit 


Name of Unit to which the Patient 
belonged when the Medication was 
Administered (all Patients who 
received pump infusions during 
timeframe selected) 


Text 


Patient 


Name of Patient 


Text 


Nurse 


Name of Nurse assigned to Patient 


Text 


Order 


RX ID and description of the order 
(i.e. RX Text) 


Text 


Administration 


Time and Date of actual 
administration — e.g. Jan 14, 2004 
1:05:00 pm (based RX Schedule ID) 


Text/ Date 


Occurrence Date 


Date and Time the Infusion rate 
changed (change in 
Mode/Status/Rate/Dose) 


Date 

(mm/dd/yyyy 
hh:mm:ss) 


Pump Mode 


Mode of Pump - Primary or 
Piggyback 


Text 


Pump Status 


Status of Pump at Occurrence Date 
(e.g. Stopped, Standby Mode) 


Text 


Rate 


Rate programmed into Pump 


Numeric 


Dose 


Dose programmed into Pump. 


Numeric 



As indicated above, and as shown in Figure 94, the system can break the data down for 
this report by at least unit, patient, nurse, order, and/or administration. The system can allow for 
searching by at least date range, unit, patient, and/or item/medication. 

Infusion Rate and Mode Comparison Summary Report 

Referring to Figures 95-97, an infusion rate and mode comparison summary report is 
shown, which lists totals of resolved mismatches, accepted mismatches, matches, and no 
comparisons for rate comparisons as well as total mode mismatches for primary or piggyback 
comparisons. 

The following exemplar data/information can be included in this report: 



Header/Label 


Description 


Data Type 


Total 


The sum of #Accepted Mismatches, 
#Matches, and#No Comparisons. 




# Resolved 
Mismatches 


Total Rate Comparisons that started 
as mismatches and ended up as 
matched 


Numeric 


# Accepted 
Mismatches 


Total Rate Comparisons that were 
mismatches and the clinician 


Numeric 
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accepted the mismatch (selected 
"Accept Mismatch") 




# Matches 


Total Rate Comparisons that were 
matches 


Numeric 


# No 

Comparisons 


Total Rate Comoarisons that had the 
"No Comparison" result 


Numeric 


Mode Mismatch 


Total Mismatches for Primary or 
Piggyback Mode (see Layout) 


Numeric 


Units 


Name of Unit to which the Patient 
belonged when the Comoarison was 
done (all Patients who received 
pump infusions during timeframe 
selected) 


Text 


Piggyback vs 
Primary (Mode) 


Split each of the "Total Rate 
Comparison" columns between 
those that were compared on the 
Primary mode or those that were 
compared on the Piggyback mode 


Text 



As indicated above, and as shown in Figures 95-97, the system can break the data down 
for these reports by at least unit, and/or piggyback vs. primary (mode). The system can allow 
for searching by at least date range and/or unit. When patients change units, and if there was a 
5 Rate Comparison done for Patient in Unit A and subsequently the Patient moves from Unit A to 

Unit B, the system can be set up to have the Rate Comparison data remain with Unit A or be 
transferred to Unit B (with or without a special indication of this change). In addition, resolved 
mismatches can be counted in the total. However, preferably they are not counted in the Total 
as they are a subset of #Matches. 



10 
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Infusion Rate Comparison Summary Report (by Medication) 

Referring to Figures 98-100, an infusion rate comparison summary by medication report 
is shown, which lists total of resolved mismatches, accepted mismatches, matches, and no 
5 comparisons for rate comparisons by medication per unit or all units in the hospital. 

The following exemplar data/information can be included in this report: 



Header/Label 


Description 


Data Type 


Total Infusions 


Total Infusions for Med in that Unit 
is the sum of # Accepted 
Mismatches, #Matches, and #No 
Comparisons. 


Numeric 


# Resolved 
Mismatches 


Total Rate Comparisons that started 
as mismatches and ended up as 
matched 


Numeric 


# Accepted 
Mismatches 


Total Rate Comparisons that were 
mismatches and the clinician 
accepted the mismatch (selected 
"Accept Mismatch") 


Numeric 


# Matches 


Total Rate Comparisons that were 
matches 


Numeric 


#No 

Comparisons 


Total Rate Comparisons that had the 
"No Comparison" result 


Numeric 


Units 


Name of Unit to which the Patient 
belonged when the Comparison was 
done (all Patients who received 
pump infusions during timeframe 
selected) 


Text 


Medication 


Specific Medications hung on 
pumps (through central computer). 


Text 



As indicated above, and as shown in Figures 98-100, the system can break the data down 
10 for these reports by at least unit and/or medication. The system can allow for searching by at 

least date range, unit, and/or item name/medication. When patients change units, and if there 
was a Rate Comparison done for Patient in Unit A and subsequently the Patient moves from 
Unit A to Unit B, the system can be set up to have the Rate Comparison data remain with Unit 
A or be transferred to Unit B (with or without a special indication of this change). In addition, 
15 resolved mismatches can be counted in the total. However, preferably they are not counted in 

the Total as they are a subset of #Matches. 

In one embodiment for Medications in relation to Infusions, business rules for 
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summarizing Infusions by Med can work as follows: 1) if infusion has 1 Item/Medication in it, 
the data is counted under that Medication; 2) if a Mixed Infusion has 2 Items in it, the data is 
counted under the Additive rather than the Solution (for example, if Infusion is Dopamine + 
D5W, any near misses for this order are counted as Dopamine); 3) if Infusion has more than 2 
Items in it (for example, 2 Additives plus Solution), the infusion will be counted by its Order 
Type (for example, Continuous Infusion, TPN, etc.). The report can display either the name of 
the drug in the infusion if the Infusion has 1 medication or can display the Order type if there 
are 2 or more ingredients. Further, for the Med Admin results, if the Order has 2 ingredients, 
the report can display the first ingredient. 

Infusion Flow Rate Comparison Report (by Patient) 

Referring to Figures 101-102, an infusion flow rate comparison by patient report is 
shown, which lists the history of flow rate comparisons for medication(s) hung on infusion 
pumps. 

The following exemplar data/information can be included in this report: 



Summary Graphs: 



Header/Label 


Description 


Data Type 


Comparison 
Results 


Total Number each of Matches, 
Mismatches, and No Comparisons 
for Rate Comparisons in the Report 
Unit 


Numeric bar 
chart 


Comparison 
Results (%) 


Percentage each of Matches, 
Mismatches, and No Comparisons 
of total Rate Comparisons in the 
Report Unit 


Numeric bar 
chart 


Body of Report: 


Header/Label 


Description 


Data Type 


Unit 


Name of Unit to which the Patient 
belonged when the Medication was 
Administered (all Patients who 
received pump infusions during 
timeframe selected) 


Text 


Nurse 


Name of Nurse who administered 
the Medication. 


Text 


Patient 


Name of Patient 


Text 


Order 


RX ID and description of the order 
(i.e. RX Text) 


Text 


Administration 
Time 


Time and Date of actual 
administration - e.g. Jan 14, 2004 


Text/ Date 
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1:05:00 pm (based RX Schedule ID) 




Pump Mode 


Mode of Pump - Primary or 
Piggyback 


Text 


Rx Rate 


Rate entered in Order 


Numeric 


Pump Rate 


Rate programmed into Pump at Rate 
Comparison 


Numeric 


Comparison 
Result 


Result Rate Compare, (e.g. Match, 
Mismatch, No Comparison) 


Text 


Date/Time 


Date and Time of the Rate 
Comparison 


Date 

(mm/dd/yyyy 
hh:mm:ss) 



As indicated above, and as shown in Figures 101-102, the system can break the data 
down for these reports by at least unit, nurse, patient, order, and/or administration time. The 
system can allow for searching by at least date range, unit, and/or patient. 
5 Dose/Rate Range Out of Limit Summary Report 

Referring to Figures 103-106, a GUARDIAN type dose/rate range out of limit summary 
report is shown, which lists total alerts for unit(s) and time period in the hospital. 

The following exemplar data/information can be included in this report: 



Header/Label 


Description 


Data Type 


# Infusions 


Total number of infusions hung 
(which can be tracked through 
central computer, in Time Period 
and selected Unit(s) 


Numeric 


# Guardian 
Alerts 


Total number of Guardian Pump 
Alerts tracked through central 
computer 


Numeric 


# Reprogrammed 
after Alerts 


Total number of times a pump was 
re-programmed after receiving a 
Guardian Alert 


Numeric 


#Accepted Alert 
Overrides 


Total number of times a pump was 
not re-programmed after Guardian 
Alert. 

#Accepted Alert Overrides = 
#Guardian Alerts-# Reprogrammed 
after Alerts 


Numeric 


Units 


Name of Unit to which the Patient 
belonged when the Comparison was 
done (all Patients who received 
infusions during timeframe selected) 


Text 



10 
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5 As indicated above, and as shown in Figures 103-106, the system can break the data 

down for these reports by at least unit. The system can allow for searching by at least date range 
and/or unit. "GUARDIAN" type data can be received by the central computer in the system, 
tracked, manipulated and provided through at least these reports. 

Dose/Rate Range Out of Limit Summary by Medication Report 
10 Referring to Figures 107-108, a GUARDIAN type dose/rate range out of limit summary 

by medication report is shown, which lists total alerts by medication for unit(s) and time period 
in the hospital. 

The following exemplar data/information can be included in this report: 



Header/Label 


Description 


Data Type 


# Infusions 


Total number of infusions hung 
through central computer in Time 
Period and selected Unit(s) 


Numeric 


# Guardian 
Alerts 


Total number of Guardian Pump 
Alerts received by central computer 


Numeric 


# Reprogrammed 
after Alerts 


Total number of times a pump was 
re-programmed after receiving a 
Guardian Alert 


Numeric 


#Accepted Alert 
Overrides 


Total number of times a pump was 
not re-programmed after Guardian 
Alert. 

#Accepted Alert Overrides = 
#Guardian Alerts-# Reprogrammed 
after Alerts 


Numeric 


Units 


Name of Unit to which the Patient 
belonged when the Comparison was 
done (all Patients who received 
infusions during timeframe selected) 


Text 


Pharmacy Label 


Specific Medications hung on 
pumps (through central computer), 
(see Notes below) 


Text 


Guardian Label 


8 character label for Medication 
used by "Guardian" Pump 


Text 



15 

As indicated above, and as shown in Figures 107-108, the system can break the data 
down for these reports by at least unit, pharmacy labels, and/or "GUARDIAN" type labels, such 
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as COLLEAGUE GUARDIAN type labels within particular embodiments of the system. The 
system can allow for searching by at least date range, unit, and/or item name such as for 
example, pharmacy label/medication. "GUARDIAN" type data can be received by the central 
computer in the system, tracked, manipulated and provided through at least these reports. 
5 In one embodiment for Medications in relation to Infusions, business rules for 

summarizing Infusions by Med can work as follows: 1) if infusion has 1 Item/Medication in it, 
the data is counted under that Medication; 2) if a Mixed Infusion has 2 Items in it, the data is 
counted under the Additive rather than the Solution (for example, if Infusion is Dopamine + 
D5W, any near misses for this order are counted as Dopamine); 3) if Infusion has more than 2 

10 Items in it (for example, 2 Additives plus Solution), the infusion will be counted by its Order 

Type (for example, Continuous Infusion, TPN, etc.). The report can display either the name of 
the drug in the infusion if the Infusion has 1 medication or can display the Order type if there 
are 2 or more ingredients. Further, for the Med Admin results, if the Order has 2 ingredients, 
the report can display the first ingredient. 

15 The central computer of the system can further track Unit Names, Pharmacy Labels, 

COLLEAGUE GUARDIAN type labels, # Infusions, # "Guardian" Alerts, and/or # 
Reprogrammed after Alerts. In one embodiment, if the # "Guardian" Alerts is 0 and the # 
Infusions is more than 0, these infusions will still appear on the report. (See Dopamine HC1 Inj 
40MG/ML and Bel's Morphine Sulfate Inj 2 MG/ML in Figure 108.) 

2 0 Alarms/Alerts Summary 

Referring to Figures 109-112, an alarm/alerts summary report is shown, which lists total 
alarms and KVO alerts for unit(s) and time period in the hospital. 

The following exemplar data/information can be included in this report: 



Header/Label 


Description 


Data Type 


Total Infusions 


Total Infusions hung on pumps for 
the Unit(s), Medication(s) and Time 
Period selected 


Numeric 


Alarms/Alerts 
Total 


Total number of Alarms + Total 
number of KVO Alerts received 
from pumps 


Numeric 


# Alarms 


Total number of Alarms received by 
central computer from pumps 


Numeric 


# KVO Alerts 


Total number of KVO Alerts 
received by central computer from 


Numeric 
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pumps 




# Escalated 


Total number Alarms and KVO 
alerts escalated to Charge Nurse 


Numeric 


Avg. Response 
Time 


Total time between start of 

alarm/alprt anH whpn thp alfirm/jilprt 
aiai 111/ ait/i t ai 1 vi wiit^ii uic< aiaiiii/uicii 

was Cleared for all Alarms and 
KVO Alerts in specified time period 
& Unit. 

This total is then divided by Total 
Alarms & KVO Alerts in specified 
time period and Unit. 
Round the average to nearest 
second. 


Time 

( mm 'cc^ 
^111111. 5o ) 


Unit 


Name of Unit to which the Patient 
belonged when the Comparison was 
done (all Patients who received 
pump infusions during timeframe 
selected) 


Text 



As indicated above, and as shown in Figures 109-1 12, the system can break the data 
down for these reports by at least unit. The system can allow for searching by at least date range 
and/or unit. In one embodiment, the number of alarms will not include all alarms received from 
the central computer, such as for example, "Loss of Communication" alarms. Thus, number of 
alarms may only be a subset of all alarms received from the central computer (e.g., Downstream 
Occlusion, Tube Not Loaded, etc.). However, in another embodiment, all alarms will be 
included in the number of alarms. In one embodiment, # Escalated is the number of alarms and 
KVO alerts escalated to "escalation level=l". Thus, such alarms would have been actually sent 
to a second Nurse (after being sent to the Nurse responsible for the patient (escalation level=0)). 

In one embodiment for the Average Response Time, for Alarms/Alerts that do not have a 
Clearance time (those that have an undefined Response Time), the central computer may need to 
track when a Pump was turned off. Further, the central computer can track when a KVO Alert 
changes to another type of Alarm/Alert (e.g., KVO Alert silenced and then it becomes a 
Channel/Pump Stopped alarm/alert because the Nurse has stopped the Pump). Under such 
circumstances, the system can use this time as the "time cleared" for the KVO Alert. # 
Alarms/Alerts silenced can be included as a part of the average response time analysis as well. 

Alarms/Alerts Summary by Unit and Alarm Condition 

Referring to Figures 113A, 113B, and 114, an alarm/alerts summary by alarm condition 
report is shown, which lists total alarms and KVO alerts for unit(s) and time period in the 



Attorney Docket No. 



(1417G P1047) 



164 

hospital split by type of alarm/alert. 

The following exemplar data/information can be included in this report: 



Header/Label 


Description 


Data Type 


Total Infusions 


Total Infusions hung on Pumps for 
the Unit(s), Medication(s) and 
Time Period selected 


Numeric 


Alarms/Alerts 
Total 


Total number of Alarms + Total 
number of KVO Alerts received 
from pumps 


Numeric 


# Alarms 


Total number of Alarms received 
by central computer from pumps 


Numeric 


# KVO Alerts 


Total number of KVO Alerts 
received by central computer from 
pumps 


Numeric 


# Escalated 


Total number Alarms and KVO 
split by Alarm Condition 


Numeric 


Avg. Response 
Time 


Total time between start of 
alarm/alert and when the 
alarm/alert was Cleared for each 

Alarms and l*C\/0 A1f*rtQ f^rvnHitinn 

in specified time period & Unit. 
This total is then divided by Total 
Alarm & KVO Alert Conditions in 
specified time period and Unit. 
Round the average to nearest 
second. 


Time 
(mm:ss) 


Unit 


Name of Unit to which the Patient 
belonged when the Comparison 
was done (all Patients who 
received pump infusions during 
timeframe selected) 


Text 


Alarm Condition 


Alarm Condition received from 
central computer 


Text 



As indicated above, and as shown in Figures 1 13A, 1 13B, and 1 14, the system can break 
5 the data down for these reports by at least unit and/or alarm condition. The system can allow for 

searching by at least date range and/or unit. In one embodiment, the number of alarms will not 
include all alarms received from the central computer, such as for example "Loss of 
Communication" alarms. Thus, number of alarms may only be a subset of all alarms received 
from the central computer (e.g. Downstream Occlusion, Tube Not Loaded, etc.). However, in 
10 another embodiment, all alarms will be included in the number of alarms. In one embodiment, # 
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Escalated is the number of alarms and KVO alerts escalated to "escalation level=l". Thus, such 
alarms would have been actually sent to a second Nurse (after being sent to the Nurse 
responsible for the patient (escalation level=0)). 

In one embodiment for the Average Response Time, for Alarms/Alerts that do not have a 
5 Clearance time (those that have an undefined Response Time), the central computer may need to 

track when a Pump was turned off. Further, the central computer can track when a KVO Alert 
changes to another type of Alarm/Alert (e.g., KVO Alert silenced and then it becomes a 
Channel/Pump Stopped alarm/alert because the Nurse has stopped the Pump). Under such 
circumstances, the system can use this time as the "time cleared" for the KVO Alert. # 
10 Alarms/Alerts silenced can be included as a part of the average response time analysis as well. 

Alarm/Alert Resolution History Report (by Alarm Condition) 

Referring to Figures 115A, 115B, and 116-118, an alarm/alerts resolution history report 
is shown, which lists the history of resolution of alarms and KVO alerts for medication hung on 
infusion pumps. 

15 The following exemplar data/information can be included in this report: 



Summary Graphs: 



Header/Label 


Description 


Data Type 


Alarms/Alerts by 
Code 


Total Number of Alarms and KVO 
Alerts per code for the Report Unit 
and time frame. 


Numeric bar 
chart 


Alarms/Alerts by 
Device (%) 


Number each of Alarms plus KVO 
Alerts per Device as a percentage of 
Total Number of Alarms plus KVO 
Alerts for the Report Unit and time 
frame 


Numeric bar 
chart 


Body of Report: 


Header/Label 


Description 


Data Type 


Alarm/Alert 
Code 


Text of Alarm/ Alert Code received 
from central computer 


Text 


Unit 


Name of Unit to which the Patient 
belonged when the Medication was 
Administered (all Patients who 
received pump infusions during 
timeframe selected) 


Text 


Patient 


Name of Patient 


Text 


Nurse 


Name of Nurse who administered 
the Medication. 


Text 
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Order 


RX ID and description of the order 
(i.e. RX Text) 


Text 


Esc. Level 


Level of Escalation of Alarm/Alert 


Numeric 


Source 


Channel Barcode? 


Text 


Device 


Device sending Alarm/Alert 
e.g. over network/PDA/Channel 


Text 


Mode 


Channel Mode where applicable 


Text 


Occurrence Time 


Date and Time of start of alarm 


Date 

(mm/dd/yyyy 
hh:mm:ss) 


Cleared Time 


Date and Time alarm was cleared 


Date 

(mm/dd/yyyy 
hh:mm:ss) 


Silenced Time 


Date and Time alarm was silenced 


Date 

(mm/dd/yyyy 
hh:mm:ss) 


Total 


Total alarms and alerts for each 
Code 


Numeric 



As indicated above, and as shown in Figures 115A, 115B, and 116-118, the system can 
break the data down for these reports by at least alarm/alert code, unit, patient, nurse, order, 
and/or occurrence time. The system can allow for searching by at least date range, unit and/or 
5 alarm/alert code. 

Alarm/Alert Resolution History Report (by Cleared/Silenced Time) 
Referring to Figures 119A, 119B, and 120-121, an alarm/alerts resolution history by 
cleared/silenced time report is shown, which lists the history of resolution of alarms and KVO 
alerts for medication hung on infusion pumps. 
10 The following exemplar data/information can be included in this report: 



Summary Graphs: 



Header/Label 


Description 


Data Type 


Response Time 


Total Number of Alarms and KVO 
Alerts responded to within 1,5, 15, 
30, and 60 minute timeframes for 
the Report Unit and time frame. 


Numeric bar 
chart 


Cleared/Silenced 
Alarms and 
KVO Alerts 


Total Number each of Cleared 
Alarms plus KVO Alerts, and 
Silenced Alarms plus KVO Alerts 
for the Report Unit and time frame 


Numeric bar 
chart 
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Body of Report: 



Header/Label 


Description 


Data Type 


Time Frame 


Unit of Time for grouping 
Cleared/Silenced alarms & alerts 
e.g. up to 1 minute, 5 minutes, 15 

uiuiuiv^o, ~jvs iiiiiiuiv^o, \jyj iiiiiiLH-t-o. 

Groups are actually <=1 minute 
Between 1 minute (& 1 second) and 
5 minutes 

Between 5 minutes (& 1 second) and 

1 S minntPQ 

1 ~J illlllul^/o 

Between 15 minutes (&. 1 second^ 
and 30 minutes 
Greater than 30 minutes 


Text 


Unit 


Name of Unit to which the Patient 
belonged when the Medication was 
Administered (all Patients who 
received pump infusions during 
timeframe selected) 


Text 


Patient 


Name of Patient 


Text 


Nurse 


Name of Nurse who administered 
the Medication. 


Text 


Order 


RX ED and description of the order 
(i.e. RX Text) 


Text 


Esc. Level 


Level of Escalation of Alarm/Alert 


Numeric 


Source 


Channel Barcode? 


Text 


Device 


Device sending Alarm/Alert 
e.g. over network/PDA/Channel 


Text 


Mode 


Channel Mode where applicable 


Text 


Occurrence 


Date and Time of start of alarm 


Date 

(mm/dd/yyyy 
hh:mm:ss) 


Cleared 


Date and Time alarm was cleared 


Date 

(mm/dd/yyyy 
hh:mm:ss) 


Silenced 


Date and Time alarm was silenced 


Date 

(mm/dd/yyyy 
hh:mm:ss) 


Total 


Total cleared/silenced alarms and 
alerts in Time Frame 


Numeric 



As indicated above, and as shown in Figures 119A, 119B, and 120-121, the system can 
break the data down for these reports by at least time frame, unit, patient, nurse, order, and/or 
5 occurrence time. The system can allow for searching by at least date range, unit and/or patient. 
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The central computer and system can be set up to tell whether the silencing of the alarm/alert 
comes from the pump or from an interface device. This information can be tracked, 
manipulated and reported. 

Alarm/Alert Resolution History Report (by Unit) 
5 Referring to Figures 122A, 122B, and 123, an alarm/alerts resolution history by unit 

report is shown, which lists the history of resolution of alarms and KVO alerts for medication 
hung on infusion pumps. 

The following exemplar data/information can be included in this report: 



Summary Graphs: 



Header/Label 


Description 


Data Type 


Alarms/Alerts by 
Device 


Total Number of Alarms and KVO 
Alerts per Device. 


Numeric bar 
chart 


Alarms/Alerts by 
Device (%) 


Total Number of Alarms and KVO 
Alerts per Device as a percentage of 
Total Alarms and KVO Alerts 


Numeric bar 
chart 


Body of Report: 


Header/Label 


Description 


Data Type 


Unit 


Name of Unit to which the Patient 
belonged when the Medication was 
Administered (all Patients who 
received pump infusions during 
timeframe selected) 


Text 


Patient 


Name of Patient 


Text 


Nurse 


Name of Nurse who administered 
the Medication. 


Text 


Order 


RX ID and description of the order 
(i.e. RX Text) 


Text 


Alarm/Alert 


Alarm Alert Name and Number 


Text 


Esc. Level 


Level of Escalation of Alarm/Alert 


Numeric 


Source 


Channel Barcode? 


Text 


Device 


Device sending Alarm/Alert 
e.g. over network/PDA/Channel 


Text 


Mode 


Channel Mode where applicable 


Text 


Occurrence Time 


Date and Time of start of alarm 


Date 

(mm/dd/yyyy 
hh:mm:ss) 


Cleared Time 


Date and Time alarm was cleared 


Date 

(mm/dd/yyyy 
hh:mm:ss) 


Silenced Time 


Date and Time alarm was silenced 


Date 
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j (mm/dd/yyyy 
I 1 hh:mm:ss) 

As indicated above, and as shown in Figures 122A, 122B, and 123, the system can break 
the data down for these reports by at least unit, patient, nurse, order, and/or occurrence time. 
The system can allow for searching by at least date range, unit and/or patient. 
5 Alarms/Alerts Summary by Medication 

Referring to Figures 124-127, an alarm/alerts summary by medication report is shown, 
which lists total alarms and KVO alerts for unit(s) and time period in the hospital split by 
medication. 

The following exemplar data/information can be included in this report: 

10 



Header/Label 


Description 


Data Type 


Total Infusions 


Total Infusions hung on pumps for 
the Unit(s), Medication(s) and Time 
Period selected 


Numeric 


Alarms/Alerts 
Total | 


Total number of Alarms + Total 
number of KVO Alerts received 
from pumps 


Numeric 


# Alarms 


Total number of Alarms received by 
central computer from pumps 


Numeric 


# KVO Alerts 


Total number of KVO Alerts 
received by central computer from 
pumps 


Numeric 


# Escalated 


Total number Alarms and KVO 
alerts escalated to Charge Nurse 


Numeric 


Avg. Response 
Time 


Total time between start of 
alarm/alert and when the alarm/alert 
was Cleared for all Alarms and 
KVO Alerts in specified time period 
& Unit. 

This total is then divided by Total 
Alarms & KVO Alerts in specified 
time period and Unit. 
Round the average to nearest 
second. 


Time 
(mm:ss) 


Unit 


Name of Unit to which the Patient 
belonged when the Comparison was 
done (all Patients who received 
pump infusions during timeframe 
selected) 


Text 
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Medication 


Totals split per Medication (see 


Text 




Notes below) 





As indicated above, and as shown in Figures 124-127, the system can break the data 
down for these reports by at least unit and/or medication. The system can allow for searching 
by at least date range, unit and/or item name/medication. In one embodiment, the number of 
5 alarms will not include all alarms received from the central computer, such as for example "Loss 

of Communication" alarms. Thus, number of alarms may only be a subset of all alarms received 
from the central computer (e.g. Downstream Occlusion, Tube Not Loaded, etc.). However, in 
another embodiment, all alarms will be included in the number of alarms. In one embodiment, # 
Escalated is the number of alarms and KVO alerts escalated to "escalation level=l". Thus, such 

10 alarms would have been actually sent to a second Nurse (after being sent to the Nurse 

responsible for the patient (escalation level=0)). 

In one embodiment for the Average Response Time, for Alarms/Alerts that do not have a 
Clearance time (those that have an undefined Response Time), the central computer may need to 
track when a Pump was turned off. Further, the central computer can track when a KVO Alert 

15 changes to another type of Alarm/Alert (e.g., KVO Alert silenced and then it becomes a 

Channel/Pump Stopped alarm/alert because the Nurse has stopped the Pump). Under such 
circumstances, the system can use this time as the "time cleared" for the KVO Alert. # 
Alarms/Alerts silenced can be included as a part of the average response time analysis as well. 

In one embodiment for Medications in relation to Infusions, business rules for 

2 0 summarizing Infusions by Med can work as follows: 1) if infusion has 1 Item/Medication in it, 

the data is counted under that Medication; 2) if a Mixed Infusion has 2 Items in it, the data is 
counted under the Additive rather than the Solution (for example, if Infusion is Dopamine + 
D5W, any near misses for this order are counted as Dopamine); 3) if Infusion has more than 2 
Items in it (for example, 2 Additives plus Solution), the infusion will be counted by its Order 

2 5 Type (for example, Continuous Infusion, TPN, etc.). The report can display either the name of 

the drug in the infusion if the Infusion has 1 medication or can display the Order type if there 
are 2 or more ingredients. Further, for the Med Admin results, if the Order has 2 ingredients, 
the report can display the first ingredient. 
Hierarchy of Reports 

3 0 Referring to Figure 128, one embodiment of a hierarchy of the reports shown in Figures 

76-127 is shown. This hierarchy can be used by the system as a part of the flow/ordering of the 
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screens which appear on the display of the interface devices. Alternatively or additionally, this 
hierarchy can be used as a part of the structuring of the database at the central computer or 
elsewhere. In particular, the Near Miss Summary Report 12802 is shown in Figures 76 and 77. 
The Near Miss Summary by Med Report 12804 is shown in Figures 78-81. The Scan Errors 
5 Report 12806 is shown in Figures 82 and 83. The Near Miss Wrong Time Summary Report 

12808 is shown in Figures 84-87. The Near Miss Wrong Time Summary by Med Report 12810 
is shown in Figures 88-91. The Near Miss Wrong Time with Reasons Codes Report 12812 is 
shown in Figures 92 and 93. The Colleague Infusion Flow Rate History Report 12820 is shown 
in Figure 94. The Colleague Infusion Rate & Mode Comparison Summary Report 12814 is 

10 shown in Figures 95-97. The Colleague Infusion Rate Comparison Summary by Med Report 

12816 is shown in Figures 98-100. The Colleague Infusion Flow Rate Comparison by Patient 
Report 12818 is shown in Figures 101 and 102. The Guardian Dose/Range Out of Limit 
Summary Report 12822 is shown in Figures 103-106. The Guardian Dose/Range Out of Limit 
Summary by Med Report 12824 is shown in Figures 107 and 108. The Colleague Alarm/Alert 

15 Summary Report 12826 is shown in Figures 109-112. The Colleague Infusion Alarms/Alerts 

Summary by Unit and Alarm Condition Report 12828 is shown in Figures 113A,B and 114. 
The Alarms/Alerts Resolutions by Alarm Condition Report 12836 is shown in Figures 115A,B 
and 116-118. The Alarms/Alerts Resolutions by Cleared/Silenced Time Report 12834 is shown 
in Figures 119A,B, 120, and 121. The Alarms/Alerts Resolution History by Unit Report 12832 

20 is shown in Figures 122A,B, and 123. The Colleague Alarms/Alerts Summary by Med Report 

12830 is shown in Figures 124-127. 

In a further embodiment, a caregiver such as for example a pharmacist can have a 
login/user level which allows for receiving reporting on pump status data for all connected 
pumps in a unit, pump status data for all connected pumps in a hospital, pump status data for all 

2 5 connected pumps which are active in the unit, and/or pump status data for all connected pumps 

which are active in the hospital. Active pumps can include, for example, pumps for which an 
infusion is being provided to a patient at the time the report is being run. The pump data, for 
example, could include the patient connected, the amount remaining to be infused, the rate of 
the infusion, the medicament being delivered, and/or any current and/or previous alarms/alerts 

30 for the delivery. 

In one embodiment, the system can be set up to automatically notify the pharmacy, one 
particular pharmacist, and/or a group of pharmacists of a particular or type of alarm and/or alert. 



Attorney Docket No. 



(1417GP1047) 



172 

In the embodiment with a first central computer and a second central computer described above, 
pump alarms and/or alerts will be received by first central computer. Once received by the first 
central computer, for particular alarms and/or alerts, or particular types of alarms and/or alerts, 
such as for example a KVO alert, the alarm and/or alert will automatically be sent to the second 
5 central computer, and to one or more pharmacists, as programmed by the system. In the 

particular example mentioned, a KVO alert can automatically be sent to a particular pharmacist 
the system knows is on duty at the time to indicate to the pharmacist that a bag of solution being 
infused to a patient is empty in real time. This allows for the pharmacist to be able to know he 
or she should fill a remaining order(s) for that patient, instead of relying on a nurse to request 

10 the the filling of an order or issue an order, or instead of waiting for a pre-scheduled time to fill 

such an order. This automatic notification also allows the pharmacist (pharmacy) to monitor the 
delivery of critical drugs to a patient through a pump. An additional example can include that 
the pharmacist (pharmacy) is automatically notified anytime a high risk IV medication alert is 
issued, for which an override is provided. A further example can include that the pharmacist 

15 (pharmacy) is automatically notified anytime a rate mismatch override is issued. 

The system can be configured to automatically send these alarms and/or alerts to the 
pharmacist (pharmacy) based on at least one of medication type, patient, unit, alarm type, and 
alert type. This information could be sent to an interface device used by a pharmacist or by the 
pharmacy, and/or printed to a pharmacist/pharmacy printer. In response to these automatic 

20 notifications, the pharmacist can provide a clinical intervention and document the outcome 

within the patient profile located at central computer, such as the second central computer. 

It should be emphasized that the above-described embodiments of the present invention, 
particularly, any "preferred" embodiments, are possible examples of implementations, merely 
set forth for a clear understanding of the principles of the invention. Many variations and 

25 modifications may be made to the above-described embodiment(s) of the invention without 

substantially departing from the spirit and principles of the invention. All such modifications 
are intended to be included herein within the scope of this disclosure and the present invention 
and protected by the following claims. 

30 



